项目复盘参考

2020-03-02 19:24:45 来源：范文大全收藏下载本文

项目管理中的复盘主要做哪些事情

1.收集和净化开发过程中各种度量数据。

收集包括工作量，规模，进度，范围，需求变更，代码行，缺陷泄漏，测试BUG分布，生产率，评审，返工等各项数据。

注意的是这些数据的收集要分散到整个项目监控过程中去，最好数据收集细化到周跟踪中，要得到第一手的数据项目中最好能够推广使用PSP Studio等相关工具，保证数据的真实性和准确性。

复盘一词应该来源于围棋，围棋一般下完棋后马上进行复盘，目的是双方都还可以清楚记得过程中得每个步骤和细节，而对于软件项目生命周期长得时候，靠复盘再去回忆是不可能完全记得清楚得，因此需要我们平时记录好这些度量数据，或者中间增加多个里程碑和检查点，及时得收集和分析数据。

2.总结项目经验教训

项目一个版本完成后，肯定既有做得好得地方也有做得不好得地方，项目本身要总结同时项目中得每个成员都应该进行自我总结。总结得目的一个是形成相关得规范和标准，避免后续版本犯同样得错误，另外一个就是形成相关得方法或模式。项目在进度紧张时候很难有足够得时间去分析和决策究竟选择那种方法或解决方案，这块每个项目必须形成相关得模式，以后遇到类似得场景就知道如何去分析和解决问题。

3.为后续版本估算提供足够得数据支持

一个项目中需求，设计，开发各阶段工作量比例究竟如何，项目得平均生产率大概在一个什么样得水平，项目在估算中评审，测试究竟需要留多少得时间?这些经验数据都需要我们从前续版本得复盘中来获取。刚开始做我们得估算很难做得准备，是因为我们没有历史经验数据可以参加，项目版本做多了，多注意复盘收集和分析数据，完全可以使我们得估算做到很准确。

复盘得实际值并不一定不加分析完全用于下一个版本得估算，实际数据本身可能也存在问题和缺陷，我们应该把这些噪音剔除掉，同时有些工作量分布比例跟我们得质量目标有密切得联系，如当我们得质量目标高得时候，则评审和测试占的工作量比例可能会更高些。

[原创]IT项目管理-项目复盘总结项目计划方面(PP)

1.通过流总数来定义用例的复杂度很难准确，且发现很多时候用例本身也偏大，但又很难去拆分它为几个子用例。（项目估算）

后期对小版本采用专家法，对大版本采用功能点法估算，并进行功能点估算培训。对于基于用例估算的时候需要考虑到对于复杂用例必须要考虑拆分出扩展用例或子用例。另外基本流，扩展流的粒度和编写原则要进一步细化，现在还存在就是一条流描述了多条业务规则，或者是本来可以一条流描述的写软件需求的时候拆分为多条描述。

2.估算没有通知到测试人员参与（项目估算）

测试的工作量和软件产品本身的规模是相关的，我们知道首先需求的规模和测试用例的规模之间根据历史经验数据可以得出一个换算比例关系。所以根据软件需求规模可以得出测试规模，根据测试规模/测试生产率后可以得到测试的工作量。因此估算需要通知到测试人员，进行测试设计和测试执行工作量估算。

3.估算的新模板很多参数和指标具体含义项目成员不熟悉（项目估算）

包括COPQ,COGQ，以及评审，返工，设计开发等工作量是如何估算出来的参与估算的项目成员并不是特别清楚。很多流程和规则都固化到了Excel模板中，虽然估算的过程简单了，但是成员并没有真正了解估算的流程和原理。

4.周例会没有和项目成员共同分析和确认风险以及风险参数

周例会需要共同分析本周发生的问题，这块BA做的好，设计开发很少提问题。周例会需要共同对已有的风险进行跟踪，并识别新风险。项目需要组织专门的风险管理培训，项目管理很多时候就是对风险的管理

5.不是所有的成员都参加了项目主计划的评审获取项目承诺

个别设计开发人员没有全部参加项目主计划内部评审，项目成员不清楚总体情况。这跟项目团队的异地化开发协调也有一定关系，但是我们仍然强调所有成员都应该参加项目计划的评审，并进行承诺，这样团队成员可以将自我项目任务和团队项目目标很好的匹配。

6.项目成员不清楚项目自定义过程和作用

项目自定义过程是IPM过程域的一个重要内容，需要对其作用了解清楚。过程裁剪的方法，原则，裁剪和项目特征之间的关系等都需要有个大致的了解。不是简单的为了进度而裁剪掉过程，评审，集成测试等重要过程裁剪掉了往往项目质量和进度更加无法保障。

7.项目在一些技术方案和实现方式选择上面没有形成规范做法

CMMI三级DAR过程域强调了项目的分析和决策，如何通过DAR来指导项目识别，分析，选择技术方案需要考虑。

8.WBS分解计划阶段没有包含风险计划分解结果

项目的风险管理过程从项目一启动就已经开始，在项目计划阶段应该包括了风险的识别，风险的分析，风险的应对措施和计划等很多内容。对于最终采取的风险应对措施和计划应该有专门的WBS摘要计划和具体的风险应对任务和活动。

项目跟踪和监控方面(PMC)

1.项目周报很难体现项目总体进度

项目周报的形式需要进行改善，项目的开发模式需要更加的体现增量和迭代开发。这样跟踪的时候可以按照功能点或需求特征点进行跟踪，根据冒烟测试的情况来使项目进度真正可视。在这一块可以引入停车场图更加直观的项目进度展现方式。

2.集成测试比预期进度延后3天左右

再次强调敏捷开发中持续集成和每日构建的概念，这个版本在这里吃亏较多，持续集成的一个重要作用就是保证测试的迭代，提前发现结队任务问题，避免设计严重泄露。

3.问题分析和跟踪机制不完善

因为经常最多的就是听到这个问题解决了没有，在谁哪里，为什么这样解决，这种解决方式有问题等词语，说明整个问题解决和跟踪机制还有待改进。组织有组织级别的资产库和经验库，项目也需要有项目级的问题和经验收集管理库。

4.设计人员对开发输出的Review力度还要加强

在团队本身不稳定或团队成员新老交替的时候，应该多采用以师带徒的模式，这个时候师傅要加强代码的Review工作，通过Review代码来尽早的发展开发质量问题，发现新员工技能存在的欠缺点，后续好开展有针对性的培训。

5.项目经理不能每周准确跟踪到进度情况

还是说到设计这块，由于没有持续集成，每周功能点也没有集成到151上来，项目经理这块很难确切跟踪到准确进度情况，所以这块建立在对设计完全信任上。 6.架构如何跟踪设计是否按照架构思路执行问题

如何保证设计和架构的一致性？这块架构要考虑下，后期如何加强控制。这也是我们IT项目管理中强调概念完整性的一个重要内容，首先需求本身不能出现偏差，其次架构和总体设计和需求匹配，设计的思路要能够严格贯彻执行。

7.任务承诺和执行的问题

PMS任务周四提出可以延后两天，周五提出需要延期的只能延后一天。但任务延期必须有明确的原因。项目经理口头或邮件的非PMS任务请大家一定注意，你承诺了在某个时间点能够搞定的要确保在时间点搞定。

验证和确认相关(VER&VAL)

1.测试人员的测试用例模板存在问题

测试一个重要环节是分支分析和测试数据的准备，这块还要考虑后续改进方法。

2.测试人员对业务的理解程度问题

这块对测试业务培训较少，测试对业务理解深度还要加强，测试有需求要尽早提出来，项目组这边会多安排BA给测试进行培训

3.测试用例本身的质量问题

测试用例本身的质量涉及到两方面的内容，一个是测试用例的编写方法，一个是测试人员对业务的理解程度。测试用例要能够全面覆盖到软件需求的内容，包括非功能性方面的软件需求。测试用例一定要能够很好的体现流程，体现数据准备，体现数据在流程中处理完成后我们分析出的期望结果。测试数据，输入，期望输出必不可少。

4.通过评审的效果和质量问题

对于需求和架构的同行评审效果较好，能够发现大部分问题。但对于设计和编码的同行评审后期进度紧张，进行的不是特别好，评审的时间点也较后，很难提前发现设计和编码问题。同时我们看到在需求和设计阶段，我们评审重点都在功能性需求上面，对于系统的易用性，可扩展性，性能等方面的非功能性需求考虑较少。

本文为人月神话博客原创文章，转载请务必注明出处。

从下围棋中看项目管理

发布人：圣才学习网发布日期：2010-06-18 11:30 共 4人浏览[大] [中] [小]

围棋中最讲究大大局观，每一步棋和每一次决策都要以大局为重，眼前或局部的利益固然重要，但往往为了整体或长远的利益必须要牺牲眼前的利益。大局观的目的只有一个，为了最终的胜利，这是唯一追求的目标。大局观说起来容易，但要做大良好的大局观却太难了，大局观首先要求我们对当前的敌我的形势做一个全面的分析，同时要预知到未来棋局的变化，这其中对未来的棋局的演化或预测往往更加重要，因为你即将下的一步棋都是为了后续的利益服务的。为了获取长远利益，往往要通过弃子来牺牲当前利益，为了占据先机要以先手为先并且防止对方脱先。当局者迷，旁观者清。只有当局者能够以旁观者的平常心来审时度势，才能够真正把握大势和棋局走向。

在项目管理中的大局观就体现在项目管理三要素的平衡上，项目管理过程就是要按照项目预定义的目标在现有的各种资源和条件下成功的完成项目。因此项目经理应该对项目管理各要素有全面的分析和了解，并根据项目执行和监控过程及时的分析偏差，纠正偏差，保证项目按照预定义过程前进。大局观的另一个要点体现在项目的风险管理过程中，风险管理就是需要项目管理者能够预先的分析出影响项目目标的所有非确定性因素，并提前采取相关的预防措施，对不确定性的事件投入预防成本，这些决策更体现到最项目整体成功的把握上面。

次序的艺术

围棋是次序的艺术，首先在下棋过程中要处处争先，走先手可以处处占尽先机，牵着对手的鼻子走。一步次序走错往往就导致全盘皆输，这在围棋中是常见的事情。项目管理中需要对活动进行排序，确定活动的依赖关系，然后按着顺序一步步做。快速跟进是项目管理中压缩进度的常用方法，但一般并不推荐采用，任何破坏次序的方法多会为项目代理额外的风险。而这些风险在项目后期全部转化为项目问题，带来巨大的纠正成本。

布局

布局阶段没有太多的激烈战斗或搏杀，但布局阶段完成往往就决定了整盘棋的走势。布局中有星，小目，中国流等多种布局，在边角还有各种定式。棋手采用什么样的布局首先是对这种布局的各种演化有很深的研究，另外就是会针对对手的情况来考虑自己的布局，往往一子未落，整个布局已经全然规划在心中。

关键字：围棋项目管理公司管理制度管理制度企业管理制度企业管理

项目管理的初始和计划阶段则对应于围棋中的布局阶段，因此计划阶段第一是要根据历史资料，经验和组织过程资产选择合适的项目管理方法论，这就是项目管理中的定式。在选择了合适的方法论和生命周期模型后才是决定在项目执行和监控中的每件事情究竟如何去做？计划就是确定howto的事情，使我们在项目的执行和控制阶段有标准，有依据。

形势判断和分析

棋手在围棋进行中盘阶段后随时都需要作形势分析，分析自己棋形的厚薄，分析自己和对手的实地的多少。厚势可以转化为实地，而实地也可能被对手侵消。通过准确的形势判断，找到棋局的关键点和必争点，找到重要的胜负手，而决定自己的下一步。

在项目管理中项目经理也需要有计划的在项目执行过程中做这种形势分析即项目监控，监控的要素除了项目的进度，范围，资源和质量外，还有项目的干系人状态，项目的风险和问题，项目的依赖和承诺，这些因素都会决定项目的成败。监控目的保证项目按计划进行，在监控过程中发现严重偏差后要及时的进行纠正。

围棋手筋

一盘围棋总离不开战斗，手筋指的就是在局部战斗中的最佳着点，一般来说，手筋是通过扑，点，尖，立，断，扳，枷，征，靠，夹，挖，接不归，挤，滚打，飞等不同的技巧组合起来在攻击，防守，对杀，收官中取得别的下法所不能取代的最佳效果。

关键字：围棋项目管理公司管理制度管理制度企业管理制度企业管理

项目管理中的最佳实践可以看做手筋，别人的最佳实践对项目是否有用就像你学了手筋后对下一盘棋是否有用一样。答案是可能有用，也可能没有用，最佳实践是在特定场景和条件下，特定的人员和资源组合条件下才是最有效的，而对于一个独立的项目是否出现这种特定的场景往往并不是一定的。我们学习了很多手筋但往往在实战中能够用到的并不是很多，因为围棋千变万化，手筋的棋形不一定走出来，所以更谈不上用了。但我们还是要学习手筋，所以更多的学习应该是学习其方法和处理问题的思路。

围棋复盘

棋手在下完一盘棋后往往都会和他人一起认真复盘，总结下棋过程中的各种得失和错误，形成相关的经验教训。棋手的提高除了多实战外，最重要的就是复盘，如果只实战了而不总结那也谈不上提高。

复盘对项目管理同样重要。而且CMMI三级开始要求项目必须进行复盘，复盘需要对项目计划，执行和控制中的各种要素的实际数据进行统计和分析，发现差距，分析引起差距的根源，形成项目的经验教训库。项目复盘不是项目经理一个人的事情，而是应该整个项目团队共同总结和分析。