项目完成了，如何做项目的总结会议？(2)

　　小芳：最后要交一个什么样的文件呢?是不是所有问题的列表就可以了?
　　阿超：列出问题，只是一个部分，重要的是让所有人了解问题的存在之后，开始讨论解决方案，要提出一个解决问题的草案。
　　原来准备开一个小时的会议进行了两个多小时才结束，食品和酒水的消耗也比原计划多了两倍，有人被抬出了河曲大酒店。
　　小芳最后把大家的意见和建议整理之后，发给了全体成员。

移山公司Stone项目Postmortem结果 整理：小芳 设想和目标 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 想做的事情还是太多，导致很长时间不能集中精力。 是否有充足的时间来做计划? 有时间，但是大部分人并不知道如何利用这一段时间来做计划。 团队在计划阶段是如何解决同事们对于计划的不同意见的？  主要通过喝酒聊天解决，另外阿超有某种“光环”，大家对他有些崇拜，这样他说的话别人都比较容易接受，不同的意见也没有特别强烈。     计划 你原计划的工作是否最后都做完了? 如果有没做完的，为什么? 很多事情都没做完，大家认为最后没做完的事情，都是可有可无的。 有没有发现你做了一些事后看来没必要或没多大价值的事? 很多，但是大家认为与其不断地争论某些事情有没有必要，不如做了再说。 是否每一项任务都有清楚定义和衡量的交付件? 大部分都没有，因为我们大家都不知道做到多少才叫“好”。有些情况下，大家对细节过早地进行讨论，花了很多时间。不如等到后来再讨论。 是否项目的整个过程都按照计划进行? 基本上，因为阿超的“光环”，大家大部分情况下都听他的。 在计划中有没有留下缓冲区，缓冲区有作用么? 有缓冲区，原来认为没有必要，后来发现还是有用的。主要是各人进度不一，有些模块不断地有一些小问题，花了很长时间才能做好。 将来的计划会做什么修改？（例如：缓冲区的定义，加班） 应该明确缓冲区的长度。   资源 我们有足够的资源来完成各项任务么? 很多情况下，花了不少时间来设置机器，以及设置用来测试的数据。 各项任务所需的时间和其他资源是如何估计的，精度如何? 开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。 用户测试的时间，人力和软件/硬件资源是否足够? 你有没有感到你做的事情可以让别人来做（更有效率）? 比如网页的CSS设计，最好由美工设计来做，开发人员最后做实现即可。我们要有专职的设计，不要临时拉人来帮忙。因为临时帮忙的设计师对整个项目了解不多，事后也找不到他。   变更管理 每个相关的员工都及时知道了变更的消息? 由于大家都坐得比较近，小道消息传播得比较快。 我们采用了什么办法决定“推迟”和“必须实现”的功能? 用了“银弹”，除了导致一场短时间的斗殴之外，还可以。银弹的目的就是一种威慑。 项目的出口条件（Exit Criteria）是否得到清晰的定义? 大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。 对于可能的变更是否能制定应急计划? 基本没有，到时候随意抓人顶上。 员工是否能够有效地处理意料之外的工作请求？ 规定所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们有大部分时间花在自己那一亩三分地上。   设计/实现 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？ 有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。 设计工作有没有碰到模棱两可的情况，团队是如何解决的？ 很多，大家都不知道如何解决。就看具体执行的人是如何解决的，有的解决得好，大家并不知道出过问题；有的经常拿出来讨论，大家都知道问题在哪里，但是没法达到一致。 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 运用了单元测试的员工，整体来看Bug不多，没有用单元测试的员工，后期比较忙。 TDD 要求PM要清楚地确定功能说明（spec），我们目前还做不到这一点。 一个好处是：大家都追着PM 要spec，弄得PM的压力很大，以前谁都不搭理PM的spec。 什么功能产生的Bug最多，为什么？ 交易功能由于牵涉的面太多，Bug也最多。 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ 刚开始还像那么回事，后来就变成走走形式。往往是“小飞，我要check-in 了，reviewer 填你的名字，怎么样？”其实小飞后来也没看代码。   测试/发布 团队是否有一个测试计划？为什么没有？ 我们有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇胡乱测试 是否进行了正式的验收测试？ 有些测试人员最后不敢说验收测试不成功，似乎是迫于某些开发人员的淫威。 团队是否有测试工具来帮助测试？ 有。 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ TFS 还是很有用的，至于改进，有这样一些建议： （a）输入Bug 还是步骤比较多，很多需要手动重复填写的字段。 （b）不是所有的Bug 或 task 都记录在TFS中。 在发布的过程中发现了哪些意外问题？ 有些功能在新的机器上不能工作，因为很多设置没有明确的定义，也没有记录。在发布的时候，这些设置没有能正确地拷贝到发布的机器上去。说明很多关于这个系统的“知识”还没有形成文字，还是保留在某些人的脑袋中

原文转自：http://www.ltesting.net