一、总结提纲
（一）Postmortem
1、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是给玩家用户提供一个休闲途径，我们的定义很明确，做一款躲避障碍的小游戏，在前面的博客中对典型用户和场景进行过明确的描述。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
很遗憾，限于精力和时间，我们仅完成了大部分目标，原计划功能已实现的有游戏基础界面，正常游戏功能（小球旋转、障碍生成和碰撞检测），积分计算和菜单栏选项功能。由于一些小问题，我们比原计划交付时间晚了几天，因为没有进行相关推广，故没有达到原计划用户数量。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于缺乏推广，用户量与预想不一致，另外通过其他团队对我们的评测复审，可以看出我们的项目游戏界面和玩法模式过于单一。因此我们离目标还有很远的一段路要走。
2、计划
- 是否有充足的时间来做计划?
是的，有充足的时间进行计划。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
先各自提出自己的想法，再由组长依据情况进行判断选择，或进行投票决定。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本工作都完成了，后面因为其他考试，限于时间精力，没有对一些完善游戏的功能进行整合
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有。
- 是否每一项任务都有清楚定义和衡量的交付件?
是的，交付件由组长和测试进行最终衡量
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目后期出了一些问题很难处理——游戏结束界面的生成，是因为前期设计的时候没有考虑好，导致后面完成该功能时会与项目整体框架发生冲突。主要原因还是缺乏项目经验吧。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有，起到一定作用。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在设计项目的时候考虑更多点，将组件要求描述更加清楚方便开发人员进行开发。
3、资源
- 我们有足够的资源来完成各项任务么？
- 人力资源：我们团队有6个人，除了PM外，有3名开发和2名测试
- 开发资源：组长整理了部分开发所需的基础知识和技术文档
- 设备资源：人手一台电脑，足够完成开发测试任务
- 时间资源：有些紧张，其他课程也有实验课设作业和考试，软工的项目时间跨度和工作量有点大。
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
组长发布任务后，由组员先自我评估，组长再结合整个项目进行评估，主观评估因此精度不是很准。
- 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
足够，美工设计上低估了难度，从其他人的复审可以看出，我们的界面过于单一。
- 你有没有感觉你做的事情可以让别人来做（更有效率）？
一般来说开发人员编程后应顺手进行单元测试，这样会比让测试人员去测试更有效率，因为此时开发对代码的整个逻辑更为熟悉。
4、变更管理
- 每个相关的员工都及时知道了变更的消息？
基本知道，成员更新代码后会上传至Coding.net，并在微信群通知一下大家。测试人员测试有问题时也会进行告知。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能？
基础功能“必须实现”，次要功能或实现难度过大则可进行“推迟”。
- 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
有，定义如下：
- 软件不崩溃闪退
- 测试发现的bug得到修复
- 典型用户场景得到测试并无bug
- 测试矩阵中的典型情况得到测试并无bug
- 对于可能的变更是否能指定应急计划？
我们进行了良好的分支管理，对于提交的功能，经过组长和测试review发现没问题后再对项目分支进行合并。即使发生意外，也可以通过回退至上一个正确版本再进行问题解决。
- 员工是否能有效地处理意料之外的工作请求？
可以，比如博客文章撰写工作量大的时候会进行轮流分配。
5、设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目开始的第一二周进行，主要由组长来完成，辅以成员讨论。时间充裕，人员合适。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
进行开发时，开发人员与组长的预想实现方式可能不一样，一般这时候会进行讨论，选出最佳解决方案。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
虽然仅是简单的一款小游戏，但我们运用过单元测试对功能模块进行测试以及利用UML进行需求分析和模块划分。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
返回主界面和游戏结束界面，由于跟早期的设计理念有一定冲突。
发布后发现图片资源无法正常加载，这导致了游戏界面过于单一。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由组长和测试进行Code Review，由于开发初期已制定代码规范，故对代码规范有做要求。
6、测试/发布
- 团队是否有一个测试计划？为什么没有？
有，详见上一篇博客。
- 是否进行了正式的验收测试？
进行过验收测试，但应该不够正式严格。
- 团队是否有测试工具来帮助测试？
仅单元测试工具，如Junit
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的效能主要是指游戏过程中的流畅性和功能的正常运行，从实际结果看，开发工作和测试工作都完成得不错。
- 在发布的过程中发现了哪些意外问题？
发布后发现界面的图片资源无法正常加载。
7、总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为到团队处于磨合和规范阶段之间，很多事情上能取得一致，但整个团队的规范仍需要完善。
- 你觉得目前最需要改进的一个方面是什么?
功能模块的划分需要更清晰明确，方便开发人员进行开发，也减少Bug的发生。角色和职责定义要落到实处，避免出现成员间任务负担失衡。
（二）讨论照片
二、团队成员在Alpha阶段的角色及贡献
| 姓名 | 角色 | 团队贡献分 | 可验证贡献 |
|---|---|---|---|
| 张鸿 | PM | 23 | 撰写博客，功能代码编写 |
| 夏浚杰 | DEV | 19 | 撰写博客，功能代码编写 |
| 萧英杰 | TEST | 20 | 撰写博客，代码测试 |
| 谢嘉帆 | DEV | 22 | 撰写博客，功能代码编写 |
| 杨辉鹏 | DEV | 21 | 撰写博客，界面开发 |
| 陈嘉曼 | TEST | 15 | 撰写博客，代码测试 |
原文地址：https://www.cnblogs.com/lingyunshangyue/p/9979655.html