【探路者】Postmortem会议（“事后诸葛亮”会议）
探路者团队贪吃蛇项目Postmortem结果
整理：米赫 蔺依铭
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的贪吃蛇游戏主要将完成一个一个背单词与传统贪吃蛇游戏玩法结合的功能，它定义得很清楚，典型用户和典型场景都有清晰的描述，就是面向所有英语学习者的一款怀旧小游戏。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们一共完成了18个功能中的17个功能，仅剩一个背景音乐功能还没有添加。已按照原计划交付时间交付。预计用户数量13人，实际用户数量16人。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
和我们预想的完全一致，甚至在用户量上超出了预期，可以这样说，我们会以更快的速度完成目标。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训有很多，最重要的一点就是让擅长的人做擅长的事，这样能发挥出集体的最高效率；还应该听取客户（玩家）的建议，开发功能应有针对性，把功能做精而不是做多。
计划
1. 是否有充足的时间来做计划?
我们有充足的时间做计划，对于计划我们开了三四次的scrum会议充分讨论，对于计划进行了细致地完善。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
持不同观点的大家分别将自己的观点提出，然后由组员进行讨论并进行质询，最后由当天的master进行主持，由组长进行裁决和说服被裁决掉的观点持有者。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
不，还没有做完，仅剩最后一个功能。背景音乐模块我们想要和音效等与音频相关的部分一起推出，beta发布敬请期待。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。在分配给组员任务的时候应量体裁衣，如果这位组员擅长什么，那就让他去做什么，而尽量不要让其在工期内从头学习去接触新的领域。想要提升自己应尽量在业余时间勤奋努力，如果不是老板授意，那就不要拿着老板的投资去充实自己。
5. 是否每一项任务都有清楚定义和衡量的交付件?
每项任务都有非常清楚的定义和衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个过程都按照了计划进行，因为项目比较小，所以并没有出什么意外。对于吃单词功能的设计我们曾经有出现争执，但是经过讨论最终留下了最符合实际的，也就是现在的这个版本。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
我们组有预留缓冲区。有作用，在课业繁忙的时间段，我们将工作计划弹性安排，并没有影响完成的工期进度。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
考虑到alpha发布后我们会有一位组员离队，重新分工是我们面临的一个大问题。也许会将我们的职责进行微调。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划很重要，计划指引着我们的工作，而不是看着工作进度去修改计划。我们会更加充分地考虑各方面因素，制定更合身的计划。
资源
1. 我们有足够的资源来完成各项任务么?
有足够的资源。我们有配置足够的设备，有相同的编译环境，有参考书籍，有掌握较好的同学进行指导，有文笔较好的同学来设计文案宣传，我们有理由相信我们可以完成各项任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
由具有开发经验的同学来负责估计，再结合自身情况安排。精度还不错，虽有误差但是只有提早完成并没有时间不够的情况发生。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试所需要的资源都足够。低估了难度，文案不好写，视频不好拍，美工不好画，真的需要领域相关的人来做这些事情，临阵磨枪很困难。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有。我曾经参与过视频制作，发现自己并不熟悉软件的使用，很低效。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
分配任务不必逞能，做到自己分内的事情就好。
变更管理
1.每个相关的员工都及时知道了变更的消息?
知道，变更主要有两种情况，一种是在会议中讨论得出的，这样每个人都有所了解，一种是在突发情况下在群里通知，会@相关的人并得到回复，如果没有及时回复会电话或人工通知。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
难度较大的非核心功能在时间紧迫的情况下推迟实现，而在需求中核心功能必须实现。例如贪吃蛇项目中贪吃蛇的基本功能是必须实现的，背景音乐等功能可以考虑推迟。这是在开会的时候与负责编码的人员安装需求逐步讨论确定的。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
没有，拿出了可以用来α发布的版本，但是还有许多功能待添加，特别是对于游戏来说，因为经验不足很难界定什么事做好了。
4.对于可能的变更是否能制定应急计划?
没有制定应急计划，因为难以估计可能的变更。
5.员工是否能够有效地处理意料之外的工作请求？
有些可以有些不可以，因为每个人都有着其他的事情，有的还要准备近期的考试，有些情况下难以为意料之外的工作分出时间。但如果时间准许，都能有效处理。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一是对项目有更精确的把控，特别是在项目初期确定需求的阶段，更明确需求以及需要产出的产品。这样可以有效的减少变更与意料之外工作的发生。二是更合理的安排任务，为时间比较紧张的人员安排较少的工作，这样可以预留出时间来响应变更。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是α周开始前两天小组成员共同讨论，最后由吴雨丹同学完成的，设计工作进行的很好，可能时间稍晚但是并没有太耽误进度。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有这种情况，例如在设计吃单词并计分的时候，大家都有一些想法但是都不能成为最终的设计。解决的办法是由负责设计的成员先完成一个方案，然后再讨论改进。这样效率比一味的讨论要高得多。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有用过。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
吃掉单词并记分的功能bug最多，这里是逻辑最复杂的部分，在实现后发现了一些之前没有考虑到的问题。比如有可能因为食物刷新到墙里导致了蛇可以进入墙体内而不导致游戏结束这样的BUG。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
有两名同学进行代码复审。代码复审时缩减版的，基本确保代码符合代码规范，但是没有对输入安全、变量函数是否可替换等问题进行复审。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学习使用单元测试来减少后期BUG的产生，特别是对逻辑复杂的功能。
测试/发布
1.团队是否有一个测试计划？为什么没有？
有负责测试的人员，但是没有制定具体的测试计划。因为没有考虑到这个问题。
2.是否进行了正式的验收测试？
在课堂上进行了演示。没有正式的验收测试
3.团队是否有测试工具来帮助测试？
测试人员在不同电脑上进行测试，没有使用自动化测试工具。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
未进行测量并跟踪软件。应该使用相关工具跟踪软件效能。
5.在发布的过程中发现了哪些意外问题？
没有意外发生。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
制定系统的测试方案，使用相关工具跟踪软件的效能
团队的角色，管理，合作
1.团队的每个角色是如何确定的，是不是人尽其才？
根据每个人的能力和所擅长的领域确定，同时也充分考虑了自愿原则，由每个人申请完成的任务。应该说是人尽其才的。
2.团队成员之间有互相帮助么？
团队成员之间有互相帮助。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
在任务分配时，可以在会议上讨论自己的想法，由组长做出决策。而在相关工作确定之后，就需要按照分配的任务执行。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
更多的考虑到大家的想法，确定更高效的决策机制，例如每个人提出自己的方案进行投票表决等。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
处于CMM阶段
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?、
处于磨合阶段
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
学会了明确分工，大家心往一处想，劲往一处使
你觉得目前最需要改进的一个方面是什么?
现在我们已经收获了许多用户的反馈建议，我们即将着手修改我们的软件，使其更贴合用户的需求。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
Simplicity--the art of maximizing the amount of work not done--is essential.
翻译: 保持简明 - 尽可能简化工作量的技艺 - 极为重要。
这条原则我们做的最好，我们在分工的时候都将任务时间预计定成最大，明确分工。
附：全组讨论照片及大家温暖的感谢
徐劭斌：http://www.cnblogs.com/xushaobin/p/7793766.html
米赫：http://www.cnblogs.com/immixiaomi/p/7794347.html
翟宇豪：http://www.cnblogs.com/-Rio56/p/7794563.html
吴雨丹：http://www.cnblogs.com/clairewyd/p/7795904.html
贾雅杰：http://www.cnblogs.com/jyj5951/p/7795914.html
蔺依铭：http://www.cnblogs.com/linym762/p/7799711.html
