团队作业7-Alpha冲刺之事后诸葛亮
事后诸葛亮分析
a.总结的提纲内容
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要解决用户无意识花钱，无法清楚看见钱去哪儿了，不能有计划花钱的问题；我们自认为定义得还算清楚；对典型用户和典型场景在之前的博客上有较清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们勉强达到目标了吧，基本功能已经能实现，原计划的功能完成了1/2；而且在课上演示过了，算是按照原计划提交了；现在用户暂时还只是同学，并未推广出去。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量因为没发布的原因暂时还不明，体验用户对重要功能的接受程度和预想基本一致，在一些方面也提出了他们的意见，有助于我们更好的改进。他们的支持是我们前进的动力，感觉在向我们的目标一步步迈近。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
对时间的把握不太到位，任务很赶，所以很多方面都还很粗糙，有的功能因为来不及就放弃了；如果历史重来一遍，我们会更合理的安排时间，尽量将各方面做细做好。
二、计划
1. 是否有充足的时间来做计划?
由于各种原因，并没有充足时间来做计划，计划也就相对较粗糙。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
同事们将意见罗列出来，各自发表自己的看法，再经由大家一起探讨，分析利弊，选择出最好的。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划工作基本做完了，只是有些方面做得还不够好，我们后面会继续改进的。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，但是这也是一种难得的体验，不是吗？
5. 是否每一项任务都有清楚定义和衡量的交付件?
有些任务并不能清楚定义，也没有衡量的交付件，比如安卓学习等；其他的也有一些只是模糊定义，一些基本的交付件还是有的。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程并没有都按照计划进行，在项目冲刺的一周里，大家发现有好多东西都要重新学习，估时有误；在加上各种实验和突发事件，有时任务并不能当天完成，一拖就影响其他任务的进度，越拖越难受。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划会更合理的估计时间，考虑更深远，以应对各种情况；缓冲区也要定义，该加班就要加班。
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了燃尽图的使用，计划的指定，每一次教训都是宝贵的财富。如果历史重来一遍，我们会考虑更深远，尽力做得更好。
三、资源
1. 我们有足够的资源来完成各项任务么?
在时间方面不是太充足，团队是新建立的，对APP等研发没有任何基础只能通过临时学习。不过各种知识方面的资源是足够的，老 师有提供网上也有教程，总体来说还是资源的总量还是能够完成基本任务的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
①、需求分析和改进、APP研发的学习，在需求分析的同时学习APP研发，大概花了一周多的时间 精度：精确到每天 一周多后 有了基本的需求报告和APP研发知识
②、第二周全组组员利用课后时间，再深入了解和学习APP研发知识 精度：第二周过后研发的基本能力已经有了
③、通过讨论，每个人的具体负责的模块，和代码规范，开始着手编写程序
④、关于博客的，是小组成员轮流编写，发布提交。精度：每个人都按时完成每日或者每周的博客
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试i的时间还算足够，人力也还OK，但由于测试经验不足，测试效果不是太好。软件/硬件资源没问题。
我们低估了美工设计和文案，最后的成品在界面上显得有些单调，几乎没有太多的美观可言。这些在BATE版本会尽量改进最大的符合客户要求
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
队友们都有在相互帮助，并没有人把自己的工作完全交给别人来做
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
①、成员分工要尽量清楚一些，避免完成重复的功能
②、代码规范一定要，提前达成共识，不然最后大家的代码合并根本看不懂也不能用
③、如果历史重来一遍，我们会尽力吧程序功能更加完善，编写单元测试代码，减少BUG的出现
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
每日立会的形势让每个团队成员都能及时获得变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们通过开会讨论，根据功能的定位和用户需求的分析来决定“推迟”和“必须实现”的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目的出口条件没有清晰的定义。
4. 对于可能的变更是否能制定应急计划?
没有。
5. 员工是否能够有效地处理意料之外的工作请求？
只能说尽力而为吧。
6.我们学到了什么? 如果历史重来一遍 我们会做什么改进?
我们学到了团队间合作的重要性，还有要培养应对变更的能力，这样才能更好的解决问题。如果历史重来，我们将增强应对变更的能力，对可能的变更制定应急计划，更好的完成我们的项目。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在Alpha阶段冲刺的时候开始的。是由全体成员一起商量讨论完成的。我们在需求分析出来后就立马讨论设计的问题， 主要的问题都是由平时有设计经验的人提的，算是合适的时间合适的人把
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计工作进行时会遇到有模棱两可的情况，一般是经过讨论、查阅资料，互相提意见、谈想法来解决的。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
对于我们团队来说，测试算是一个难题，我们在测试中也没有用到所说的工具并不知道效果
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
记账本APP主要的增删改查是基本功能会有些BUG，APP在没有经验的情况下对我们有些难度。 发布后客户有反映一些BUG，其 中有个为密码找回功能无效。在设计阶段我们又考虑到密码找回，但在研发时主要为基本功能的开发一致没有完善密码找回功能。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
一人写完自己的代码之后，交由另一人复审。也可能会交由多人复审
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们的编程基础有了一定的提升，学习到了如何研发一个基本你的手机APP，提升了自己的自学能力。如果历史重来一遍，我吗将尽最大的努力让界面更美观，尽量减少BUG
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划。
2. 是否进行了正式的验收测试？
没有进行正式的，团队成员以用户的角度进行了验收。
3. 团队是否有测试工具来帮助测试？
想用，但对这方面不太懂，所以没用。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队根据团队成员使用测试来测量并跟踪软件的效能的；从软件实际运行的结构来看，我们通过这找到并修复了一些bug，还是很有用的，就是测试工作应该更详细一些。
5. 在发布的过程中发现了哪些意外问题？
发布的过程还是挺顺利的，没什么大意外。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了程序测试，但做得还不是很好，如果历史重来一遍，我们将更加完善我们的测试内容。
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队的每个角色是根据团队成员擅长什么技能来确定的，虽然有些方面并没有人擅长，但通过协商也能很好解决，基本上能达到人尽其才。
2. 团队成员之间有互相帮助么？
团队是一个整体，每个项目的完成与每个成员的相互协作是分不开的，互相帮助是必不可少的。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
所有人都暂时停下手头工作，在一起开个小型会议，团队成员发表自己的看法，最后商讨出解决方案。
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了合理分配团队角色的重要性，人尽其才才能更好更快的完成团队任务，发生冲突要妥善处理，多听听他人意见，才能更好的解决问题。如果历史重来，我们会更好地分配团队角色，加强团队成员间的合作，更用心处理好团队间的冲突，力求更好。
八、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前的状态基本处于可重复级
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得团队通过Alpha冲刺后有了一定的进步，正处于磨合与规范之间，仍需继续努力。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：团队成员对开发有了更深的了解，团队成员间的配合更加好，团队在不断进步中。
4.你觉得目前最需要改进的一个方面是什么?
我觉得目前最需要改进的是测试方面，Alpha阶段我们在这方面做得很差。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
(1)“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作”----我们团队成员都是一个班级的，这点达到并不是很难。
(2)“在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈”----与上一个一样，遇到冲突问题，面对面小会议解决问题。
(3)“可以工作的软件是进度主要的度量标准。”
b.照片
团队成员在Alpha阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
| · 杨海亮 | Dev | 19 | 后端代码编写 |
| · 陈鑫旭 | Front end | 19 | 前端代码编写 |
| · 余昕宇 | Test | 19 | 测试代码编写 |
| · 陈建章 | DEV | 19 | 后端代码编写 |
| · 郑靖涛 | Front end | 25 | 前端代码编写 |
| · 李永豪 | PM | 19 | 前端代码编写 |
