一个里程碑结束了,下面怎么办? 团队有什么经验教训? 产品怎么才能做得更好? 我们常说 “软件的生命周期”- 这个软件开发的周期结束了,我们能不能像医学的尸体解剖一样,把这个软件开发的流程解剖一下?
Postmortem,Retrospective,Review,事后诸葛亮会议， 就是为了解决这一问题。
产品发布了，大家松了一口气。阿超建议大家开一个总结会议，就是事后诸葛亮会议。会议请公司的秘书小芳主持并作记录。为了让大家能畅所欲言，阿超和大牛没有参加会议。为了活跃气氛，小芳还买了零食、饮料、河曲啤酒等。
阿超给小芳一个讨论的模板，同时也嘱咐小芳不一定要拘泥于模板，要见机行事，根据会议的进展灵活地变动计划。要牢记会议的核心问题是“如果你可以重新来过，什么方面可以做得更好？”
| 现代软件工程 项目Postmortem模板 邹欣 现代软件工程 课件 2011
设想和目标 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 2.是否有充足的时间来做计划? 3.团队在计划阶段是如何解决同事们对于计划的不同意见的？ 如果历史重来一遍,我们会做什么改进?
计划 1.你原计划的工作是否最后都做完了?如果有没做完的，为什么? 2.有没有发现你做了一些事后看来没必要或没多大价值的事? 3.是否每一项任务都有清楚定义和衡量的交付件? 4.是否项目的整个过程都按照计划进行? 5.在计划中有没有留下缓冲区，缓冲区有作用么? 6.将来的计划会做什么修改？（例如：缓冲区的定义，加班） 如果历史重来一遍,我们会做什么改进?
资源 1.我们有足够的资源来完成各项任务么? 2.各项任务所需的时间和其他资源是如何估计的，精度如何? 3.用户测试的时间，人力和软件/硬件资源是否足够? 4.你有没有感到你做的事情可以让别人来做（更有效率）?
如果历史重来一遍,我们会做什么改进?
变更管理 1.每个相关的员工都及时知道了变更的消息? 2.我们采用了什么办法决定“推迟”和“必须实现”的功能? 3.项目的出口条件（Exit Criteria –什么叫“做好了”）有清晰的定义么? 4.对于可能的变更是否能制定应急计划? 5.员工是否能够有效地处理意料之外的工作请求？
如果历史重来一遍,我们会做什么改进?
设计/实现 1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？ 3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？ 4.什么功能产生的Bug最多，为什么？ 5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
如果历史重来一遍,我们会做什么改进?
测试/发布 1.团队是否有一个测试计划？为什么没有？ 2.是否进行了正式的验收测试？ 3.团队是否有测试工具来帮助测试？ 4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ 5.在发布的过程中发现了哪些意外问题？ 如果历史重来一遍,我们会做什么改进?
|
怎么开好一个 Postmortem 会议:
-
保持会议轻松愉快的氛围,可以考虑换一个开会的环境,有饮料,零食,音乐的帮助更好
-
当 [大官] 的最好不要出现,让大家畅所欲言。 (即使出现,也要夹着尾巴,不要为自己以前的行为辩护,作好听众)
-
坚持对事不对人的原创,强调 - 如果再有一次机会,会如何改进？ 而不是挖历史旧帐.
-
照顾到模板提及的各个领域,可以深入团队最感兴趣的部分。
-
让所有人都有充分发言的机会。
-
有人记录发言要点,最后列出所有改进意见
-
最后大家可以投票,如果我只有三票,投给哪些改进意见
-
大官们保证要采取行动,执行票数最高的一些改进意见。
小芳：最后要交一个什么样的文件呢？是不是所有问题的列表就可以了？
阿超：列出问题，只是一个部分，重要的是让所有人了解问题的存在之后，开始讨论解决方案，要提出一个解决问题的草案。
原来准备开一个小时的会议进行了两个多小时才结束，食品和酒水的消耗也比原计划多了两倍，有人被抬出了河曲大酒店。
小芳最后把大家的意见和建议整理之后，发给了全体成员。
| 移山公司Stone项目Postmortem结果 整理：小芳 设想和目标 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 想做的事情还是太多，导致很长时间不能集中精力。 2.是否有充足的时间来做计划? 有时间，但是大部分人并不知道如何利用这一段时间来做计划。 3.团队在计划阶段是如何解决同事们对于计划的不同意见的？ 主要通过喝酒聊天解决，另外阿超有某种“光环”，大家对他有些崇拜，这样他说的话别人都比较容易接受，不同的意见也没有特别强烈。
计划 1.你原计划的工作是否最后都做完了?如果有没做完的，为什么? 很多事情都没做完，大家认为最后没做完的事情，都是可有可无的。 2.有没有发现你做了一些事后看来没必要或没多大价值的事? 很多，但是大家认为与其不断地争论某些事情有没有必要，不如做了再说。 3.是否每一项任务都有清楚定义和衡量的交付件? 大部分都没有，因为我们大家都不知道做到多少才叫“好”。有些情况下，大家对细节过早地进行讨论，花了很多时间。不如等到后来再讨论。 4.是否项目的整个过程都按照计划进行? 基本上，因为阿超的“光环”，大家大部分情况下都听他的。 5.在计划中有没有留下缓冲区，缓冲区有作用么? 有缓冲区，原来认为没有必要，后来发现还是有用的。主要是各人进度不一，有些模块不断地有一些小问题，花了很长时间才能做好。 6.将来的计划会做什么修改？（例如：缓冲区的定义，加班） 应该明确缓冲区的长度。 资源 1.我们有足够的资源来完成各项任务么? 很多情况下，花了不少时间来设置机器，以及设置用来测试的数据。 2.各项任务所需的时间和其他资源是如何估计的，精度如何? 开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。 3.用户测试的时间，人力和软件/硬件资源是否足够? 4.你有没有感到你做的事情可以让别人来做（更有效率）? 比如网页的CSS设计，最好由美工设计来做，开发人员最后做实现即可。我们要有专职的设计，不要临时拉人来帮忙。因为临时帮忙的设计师对整个项目了解不多，事后也找不到他。 变更管理 1.每个相关的员工都及时知道了变更的消息? 由于大家都坐得比较近，小道消息传播得比较快。 2.我们采用了什么办法决定“推迟”和“必须实现”的功能? 用了“银弹”，除了导致一场短时间的斗殴之外，还可以。银弹的目的就是一种威慑。 3.项目的出口条件（Exit Criteria）是否得到清晰的定义? 大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。 4.对于可能的变更是否能制定应急计划? 基本没有，到时候随意抓人顶上。 5.员工是否能够有效地处理意料之外的工作请求？ 规定所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们有大部分时间花在自己那一亩三分地上。 设计/实现 1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？ 有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。 2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？ 很多，大家都不知道如何解决。就看具体执行的人是如何解决的，有的解决得好，大家并不知道出过问题；有的经常拿出来讨论，大家都知道问题在哪里，但是没法达到一致。 3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？ 运用了单元测试的员工，整体来看Bug不多，没有用单元测试的员工，后期比较忙。 TDD要求PM要清楚地确定功能说明（spec），我们目前还做不到这一点。 一个好处是：大家都追着PM要spec，弄得PM的压力很大，以前谁都不搭理PM的spec。 4.什么功能产生的Bug最多，为什么？ 交易功能由于牵涉的面太多，Bug也最多。 5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ 刚开始还像那么回事，后来就变成走走形式。往往是“小飞，我要check-in了，reviewer填你的名字，怎么样？”其实小飞后来也没看代码。 测试/发布 1.团队是否有一个测试计划？为什么没有？ 我们有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇胡乱测试 2.是否进行了正式的验收测试？ 有些测试人员最后不敢说验收测试不成功，似乎是迫于某些开发人员的淫威。 3.团队是否有测试工具来帮助测试？ 有。 4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ TFS还是很有用的，至于改进，有这样一些建议： （a）输入Bug还是步骤比较多，很多需要手动重复填写的字段。 （b）不是所有的Bug或task都记录在TFS中。 5.在发布的过程中发现了哪些意外问题？ 有些功能在新的机器上不能工作，因为很多设置没有明确的定义，也没有记录。在发布的时候，这些设置没有能正确地拷贝到发布的机器上去。说明很多关于这个系统的“知识”还没有形成文字，还是保留在某些人的脑袋中。 |
