一、总结提纲

（一）Postmortem

1、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   我们的软件主要是给玩家用户提供一个休闲途径，我们的定义很明确，做一款躲避障碍的小游戏，在前面的博客中对典型用户和场景进行过明确的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
   很遗憾，限于精力和时间，我们仅完成了大部分目标，原计划功能已实现的有游戏基础界面，正常游戏功能（小球旋转、障碍生成和碰撞检测），积分计算和菜单栏选项功能。由于一些小问题，我们比原计划交付时间晚了几天，因为没有进行相关推广，故没有达到原计划用户数量。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   由于缺乏推广，用户量与预想不一致，另外通过其他团队对我们的评测复审，可以看出我们的项目游戏界面和玩法模式过于单一。因此我们离目标还有很远的一段路要走。

2、计划

1. 是否有充足的时间来做计划?
   是的，有充足的时间进行计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   先各自提出自己的想法，再由组长依据情况进行判断选择，或进行投票决定。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   基本工作都完成了，后面因为其他考试，限于时间精力，没有对一些完善游戏的功能进行整合
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   暂时没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
   是的，交付件由组长和测试进行最终衡量
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   项目后期出了一些问题很难处理——游戏结束界面的生成，是因为前期设计的时候没有考虑好，导致后面完成该功能时会与项目整体框架发生冲突。主要原因还是缺乏项目经验吧。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   有，起到一定作用。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   在设计项目的时候考虑更多点，将组件要求描述更加清楚方便开发人员进行开发。

3、资源

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

• 人力资源：我们团队有6个人，除了PM外，有3名开发和2名测试
• 开发资源：组长整理了部分开发所需的基础知识和技术文档
• 设备资源：人手一台电脑，足够完成开发测试任务
• 时间资源：有些紧张，其他课程也有实验课设作业和考试，软工的项目时间跨度和工作量有点大。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
   组长发布任务后，由组员先自我评估，组长再结合整个项目进行评估，主观评估因此精度不是很准。
3. 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
   足够，美工设计上低估了难度，从其他人的复审可以看出，我们的界面过于单一。
4. 你有没有感觉你做的事情可以让别人来做（更有效率）？
   一般来说开发人员编程后应顺手进行单元测试，这样会比让测试人员去测试更有效率，因为此时开发对代码的整个逻辑更为熟悉。

4、变更管理

1. 每个相关的员工都及时知道了变更的消息？
   基本知道，成员更新代码后会上传至Coding.net，并在微信群通知一下大家。测试人员测试有问题时也会进行告知。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
   基础功能“必须实现”，次要功能或实现难度过大则可进行“推迟”。
3. 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
   有，定义如下：
   • 软件不崩溃闪退
   • 测试发现的bug得到修复
   • 典型用户场景得到测试并无bug
   • 测试矩阵中的典型情况得到测试并无bug
4. 对于可能的变更是否能指定应急计划？
   我们进行了良好的分支管理，对于提交的功能，经过组长和测试review发现没问题后再对项目分支进行合并。即使发生意外，也可以通过回退至上一个正确版本再进行问题解决。
5. 员工是否能有效地处理意料之外的工作请求？
   可以，比如博客文章撰写工作量大的时候会进行轮流分配。

5、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   设计工作在项目开始的第一二周进行，主要由组长来完成，辅以成员讨论。时间充裕，人员合适。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   进行开发时，开发人员与组长的预想实现方式可能不一样，一般这时候会进行讨论，选出最佳解决方案。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
   虽然仅是简单的一款小游戏，但我们运用过单元测试对功能模块进行测试以及利用UML进行需求分析和模块划分。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   返回主界面和游戏结束界面，由于跟早期的设计理念有一定冲突。
   发布后发现图片资源无法正常加载，这导致了游戏界面过于单一。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   由组长和测试进行Code Review，由于开发初期已制定代码规范，故对代码规范有做要求。

6、测试/发布

1. 团队是否有一个测试计划？为什么没有？
   有，详见上一篇博客。
2. 是否进行了正式的验收测试？
   进行过验收测试，但应该不够正式严格。
3. 团队是否有测试工具来帮助测试？
   仅单元测试工具，如Junit
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   软件的效能主要是指游戏过程中的流畅性和功能的正常运行，从实际结果看，开发工作和测试工作都完成得不错。
5. 在发布的过程中发现了哪些意外问题？
   发布后发现界面的图片资源无法正常加载。

7、总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
   达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
   我认为到团队处于磨合和规范阶段之间，很多事情上能取得一致，但整个团队的规范仍需要完善。
3. 你觉得目前最需要改进的一个方面是什么?
   功能模块的划分需要更清晰明确，方便开发人员进行开发，也减少Bug的发生。角色和职责定义要落到实处，避免出现成员间任务负担失衡。

（二）讨论照片

二、团队成员在Alpha阶段的角色及贡献

姓名	角色	团队贡献分	可验证贡献
张鸿	PM	23	撰写博客，功能代码编写
夏浚杰	DEV	19	撰写博客，功能代码编写
萧英杰	TEST	20	撰写博客，代码测试
谢嘉帆	DEV	22	撰写博客，功能代码编写
杨辉鹏	DEV	21	撰写博客，界面开发
陈嘉曼	TEST	15	撰写博客，代码测试