事后诸葛亮

一、团队讨论照片

二、设想与目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述

• 我们的软件主要是做一个闯关类游戏，加入自己的特有元素，对操作有一定的改进。
• 定义清楚，核心就是做一个有特色的闯关类游戏。
• 对典型用户及典型场景描述清晰，主要针对有闯关游戏爱好的人群，是一款休闲娱乐的小游戏。

2、 .我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

完成了大部分的玩法，但仍有少部分操作方面的bug。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

由于未对软件进行发布，所以用户量和用户对功能的接受程度无法估计，所以我们并没有离目标更近。

4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

我们没有做好需求分析,对具体功能的实现没有概念.以至于开发过程非常混乱

如果再来一次,我会预想想好每个功能实现的细节,确定好每一个函数。

三、计划

1、是否有充足的时间来做计划？

有。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

集体讨论，统一方案。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

大多完成了。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

把一些简单的问题想的太过复杂，导致代码量多出许多，后面又删改了。

5.我们学到了什么? 如果历史重来一遍,我们会做什么改进?

计划应该在开发前就做的非常详细,而不是模糊的定一个功能。

四、资源

1. 我们有足够的资源来完成各项任务么?

有

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

通过任务的复杂程度和人员的能力来估计,精度实际上很粗劣.对队员的实际速度也不了解。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

较为足够，在预估范围内

五、变更管理

1. 每个相关的成员都及时知道了变更的消息?

是的

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

采用四象限法则，在时间紧急的情况下，召开全体线上会议对剩余未实现功能进行“重要紧急”、“重要不紧急”、“紧急不重要”、“不重要不紧急”的分类，排出优先级。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

没有bug,能够正常运行

4. 对于可能的变更是否能制定应急计划?

能

六、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计功能在需求分析的阶段和冲刺阶段,需求分析阶段仅仅由队长完成,冲刺阶段一起讨论.

队长的设计不够清晰,应该和队友多讨论,多花时间确定一个清晰的方案.

冲刺阶段需要做的设计反而太多了,而且一直在修改,时间不合适.

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有,大家一起经过讨论后得出结果

4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码在提交之后,会有人阅读.但实际上规范性不是很强.

七、测试/发布

1. 团队是否有一个测试计划？为什么没有？

有

2. 是否进行了正式的验收测试？

是。

3. 团队是否有测试工具来帮助测试？

无

4. 在发布的过程中发现了哪些意外问题？

没有

5、我们学到了什么? 如果重来一遍，我们会做什么改进？

要善用工具进行自动化测试，扩大试用的用户范围。

八、总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

二级

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

磨合阶段

3.你觉得目前最需要改进的一个方面是什么?

沟通

成员名称	角色	团队贡献分	可验证的贡献
李兆海	开发	21.5	游戏备份，博客撰写
卢柏铖	开发	20.5	登录界面的设计
陈家健	开发	21	添加障碍物，碰撞检测
陈健	开发	20	制作精灵，音效管理
陈乙鑫	开发	22	地图设计，游戏ui的制作
陈蜀毅	开发	19.5	障碍的多样性，博客撰写
杜仲谋	测试	19	测试，博客撰写