一、前言

最近不是刚好项目结项嘛，组里就拉着开了一个复盘会，也是第一次复盘吧，没啥经验，不过一场下来，收获也还是有的。

项目复盘不是追责，只是更好的看到整个项目过程，从中找出不足的地方，加以探讨和解决此类问题，避免再放。也可以从中找到优秀的部分，继续保持，当然总归也是有糖和大棒，激励的同时也敲打敲打，避免过度自傲。

自傲这可不兴有啊，如现代版孔乙己，在复盘会上，'孔乙己'便涨红了脸，额上的青筋条条绽出，争辩道，“bug不能算错…bug！…程序员的事，能算错么？”接连便是难懂的话，什么“君子固穷”，什么“者乎”之类，引得众人都哄笑起来：会议室内外充满了快活的空气。”

这都是外话了，下面我们来看看这次复盘吧。

二、复盘步骤

1、目标回顾

回顾了一下一开始，我们打算做什么，目标是什么，计划又是如何制订的，还有就是预期的结果等等。

2、结果陈述

复盘很重要的就是结果的陈述，实事求是，进展如何，成果有哪些，错误和不足又有哪些，计划是否变化等等。

前两步基本上都不会出现什么问题，毕竟是既定事实，参与的成员基本都是知晓的，无非就是将事实再陈述一遍而已。

3、过程分析

这里主要是抓一些不足和典型问题出来分析讨论，目的是避免再犯同类型的错误或者说是优化不足的地方。

而这里也是经常开着开着就变味的地方。

本文以一个小菜比程序员的角度来看待这次复盘。

众所周知，一般的项目开发都会有提测这一环节，而测试提出的bug单数量，又是作为领导评定项目代码质量的关键一环。

bug单中分几类，如与需求不符错误类，页面功能逻辑错误类，ui样式不符，改进建议等等（分类随意，看具体情况吧），复盘可以从每个类型中抽取一两个问题出来分析。

为什么说变味呢，因为是bug单，所以基本就有对应的负责人员，由负责人员自己阐述bug出现的原因，当时的解决方式，今后如何规避等等。

如果脸皮薄点但又比较自傲的，那上面说到的'孔乙己'不就来了，可能说着说着就变成了追责大会了，与我们的目的背道而驰。

所以开项目复盘，我们应该就事论事，一心想着把项目越做越好，才会有所收获。

4、规律总结、有效沟通

如果过程分析能够顺利，基本上我们就能有所收获。

如上面提到的与需求不符错误类的bug，这完全可以在开发阶段多跟需求沟通来规避掉。

页面功能逻辑错误类的bug，这种的话，

首先是先约定好各类参数的格式，严格安装设计定义的接口文档来撰写代码，可以规避一部分因为参数导致的bug；

其次是开发过程中，数据量一定要有，不要怕麻烦，基本上很多问题都是在有数据的情况下才会暴露出来的；

然后是开发自测，这里指的是整体的自测，自测的环节很重要，很多时候我们都习惯开发完了就撒手不管了，
但其实整体开发完之后，整体自测下来，既能降低bug率，还能加深对项目业务逻辑的了解，能从中收获不少吧。

至于ui样式不符，改进建议等等，这种就靠细心和经验了。

三、小结

总的来说，项目复盘是有必要的，不管是对我们自身而言，还是对项目而言，都是有好处的。

不过要切记，切勿开成批斗追责大会，不然会适得其反，搞得项目成员怨气冲天。

ps: 我是地霊殿__三無，希望能帮到你。