项目管理中的复盘主要做哪些事情1.收集和净化开发过程中各种度量数据。收集包括工作量，规模，进度，范围，需求变更，代码行，缺陷泄漏，测试BUG分布，生产率，评审，返工等各项数据。注意的是这些数据的收集要分散到整个项目监控过程中去，最好数据收集细化到周跟踪中，要得到第一手的数据项目中最好能够推广使用PSPStudio等相关工具，保证数据的真实性和准确性。复盘一词应该于围棋，围棋一般下完棋后马上进行复盘，目的是双方都还可以清楚记得过程中得每个步骤和细节，而对于软件项目生命周期长得时候，靠复盘再去回忆是不可能完全记得清楚得，因此需要我们平时记录好这些度量数据，或者中间增加多个里程碑和检查点，及时得收集和分析数据。2.总结项目经验教训项目一个版本完成后，肯定既有做得好得地方也有做得不好得地方，项目本身要总结同时项目中得每个成员都应该进行自我总结。总结得目的一个是形成相关得规范和标准，避免后续版本犯同样得错误，另外一个就是形成相关得方法或模式。项目在进度紧张时候很难有足够得时间去分析和决策究竟选择那种方法或解决方案，这块每个项目必须形成相关得模式，以后遇到类似得场景就知道如何去分析和解决问题。3.为后续版本估算提供足够得数据支持一个项目中需求，设计，开发各阶段工作量比例究竟如何，项目得平均生产率大概在一个什么样得水平，项目在估算中评审，测试究竟需要留多少得时间?这些经验数据都需要我们从前续版本得复盘中来获取。刚开始做我们得估算很难做得准备，是因为我们没有历史经验数据可以参加，项目版本做多了，多注意复盘收集和分析数据，完全可以使我们得估算做到很准确。复盘得实际值并不一定不加分析完全用于下一个版本得估算，实际数据本身可能也存在问题和缺陷，我们应该把这些噪音剔除掉，同时有些工作量分布比例跟我们得质量目标有密切得联系，如当我们得质量目标高得时候，则评审和测试占的工作量比例可能会更高些。知识参考+1[原创]IT项目管理-项目复盘总结项目计划方面(PP)1.通过流总数来定义用例的复杂度很难准确，且发现很多时候用例本身也偏大，但又很难去拆分它为几个子用例。（项目估算）后期对小版本采用专家法，对大版本采用功能点法估算，并进行功能点估算培训。对于基于用例估算的时候需要考虑到对于复杂用例必须要考虑拆分出扩展用例或子用例。另外基本流，扩展流的粒度和编写原则要进一步细化，现在还存在就是一条流描述了多条业务规则，或者是本来可以一条流描述的写软件需求的时候拆分为多条描述。2.估算没有通知到测试人员参与（项目估算）测试的工作量和软件产品本身的规模是相关的，我们知道首先需求的规模和测试用例的规模之间根据历史经验数据可以得出一个换算比例关系。所以根据软件需求规模可以得出测试规模，根据测试规模/测试生产率后可以得到测试的工作量。因此估算需要通知到测试人员，进行测试设计和测试执行工作量估算。3.估算的新模板很多参数和指标具体含义项目成员不熟悉（项目估算）包括COPQ,COGQ，以及评审，返工，设计开发等工作量是如何估算出来的参与估算的项目成员并不是特别清楚。很多流程和规则都固化到了Excel模板中，虽然估算的过程简单了，但是成员并没有真正了解估算的流程和原理。4.周例会没有和项目成员共同分析和确认风险以及风险参数周例会需要共同分析本周发生的问题，这块BA做的好，设计开发很少提问题。周例会需要共同对已有的风险进行跟踪，并识别新风险。项目需要组织专门的风险管理培训，项目管理很多时候就是对风险的管理5.不是所有的成员都参加了项目主计划的评审获取项目承诺个别设计开发人员没有全部参加项目主计划内部评审，项目成员不清楚总体情况。这跟项目团队的异地化开发协调也有一定关系，但是我们仍然强调所有成员都应该参加项目计划的评审，并进行承诺，这样团队成员可以将自我项目任务和团队项目目标很好的匹配。6.项目成员不清楚项目自定义过程和作用项目自定义过程是IPM过程域的一个重要内容，需要对其作用了解清楚。过程裁剪的方法，原则，裁剪和项目特征之间的关系等都需要有个大致的了解。不是简单的为了进度而裁剪掉过程，评审...