事后诸葛亮分析
1.设想和目标
我们的软件要解决用户想聊天却找不到人时，可以在网络上找到有缘人排泄情绪。在前面的博客中已经有很清楚的定义和对典型用户和典型场景有清晰的描述。
该团队APP漂流瓶已经按时交付了。作为一个漂流瓶APP，主要功能仍捡漂流瓶和聊天功能已经实现了，但是原计划的好友功能由于各种原因没有实现。
漂流瓶APP自发布以来收到广泛好评，目标已经实现了，但由于宣传范围小，用户量还没达到几千。
2.计划
团队有充足的时间来做计划，同事们对于计划的不同意见时，先相互辩论，如若不能解决，则采取各退一步的方式进一步协商。
原计划设计了很多功能，但由于时间原因只能做了基本需求，APP可以用，但要长久吸引用户还需继续开发新的功能。
每一项任务都有清楚定义和衡量的交付件，基本上没什么发现做了一些事后看来没必要或没多大价值的事，一步一步探索都是值得的。
项目的整个过程没有都按照计划进行，对于每日规划的任务有时没有当日完成。
将来的计划会对一些冗余的代码进行优化，并且可行的话增加一下新功能。
3.资源
资源不太充足，比如时间和人力，物力资源。
好的程序需要更多的时间和更多的人力，还有服务器、宣传所需的资金等等。
各项任务所需的时间和其他资源是根据其复杂度和开发者的熟练程度估计的，精度比较准确。
测试的时间比较少，能用于测试的软硬件资源也比较少，有些还需要资金。
4.变更管理
由于队员都是同个宿舍，每个相关的员工都及时知道了变更的消息。
我们采用了根据APP的主要目标和难易程度决定“推迟”和“必须实现”的功能。
项目的出口条件（Exit Criteria – 什么叫“做好了”）在前面博客已有清晰的定义。
对于可能的变更能制定应急计划。
组员都能够有效地处理意料之外的工作请求。
5.设计/实现
设计工作在项目之初由组员共同协商完成。
设计工作碰到模棱两可的情况时，团队采取走一步算一步策略，遇到困难时协商或者上网查找习惯资料。
团队运用了单元测试（unit test）。
聊天功能产生的Bug最多，因为代码量非常大，需要掌握的知识储备也多。
代码复审（Code Review）是由编写者自己复审，严格执行了代码规范。
6.测试/发布
团队有一个测试计划，在之前博客已经发布过了。也进行了正式的验收测试，团队测试工具有来帮助测试。
从软件实际运行的结果来看，这些测试工作都很有用。
在发布的过程中发现有人注册不了，排查过后才知道是密码长度问题。
7.团队的角色，管理，合作
团队的每个角色在项目开始之初已经分配好了，人尽其才。
团队成员之间互相帮助，取长补短，共进退。
没有出现项目管理、合作方面的问题。
8.总结:
团队目前的状态属于 CMM/CMMI 中的已定义级档次。
团队目前处于规范阶段。
目前最需要改进的一个方面是能力还需提升。
对照敏捷开发的原则, 我们小组做得最好的是以下原则：
1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；
2-要不断交付可用的软件，周期从几周到几个月不等，越短越好
3-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
4-可用的软件是衡量进度的主要指标
5-要做到简洁，尽可能减少不必要的工作，这是一门艺术
9.全组讨论的照片
团队成员在Alpha阶段的角色和具体贡献（总分80分）
| 名字 | 角色 | 团队贡献分 |
|---|---|---|
| 蔡鑫源 | dev | 20 |
| 罗汉光 | pm | 24 |
| 纪培浩 | dev | 22 |
| 拜合提亚尔 | test | 14 |
