说起迭代评审会相信大家都不陌生，但是对于这个迭代评审会到底怎么开，相信大家都有自己的理解，每个团队的实践也不尽相同，下面介绍一下我加入团队一年来参加过的四个版本的迭代评审会，希望能对大家有一些参考价值。

版本一：“阴谋大会”

在加入我司之前，我在其他的公司也做过几年的敏捷开发，可是直到我入职我司之后，我才算真正的接触到严格意义上的迭代评审会。刚开始的迭代评审会只有PO（产品负责人）/PM（项目经理），BA（业务分析师），QA（测试工程师）和TL（TechLead）会参加，时间是每个迭代开始的第一天下午，这四个人会聚集在一个小黑屋里，然后QA（测试工程师）掏出他的小本本，上面记录了前一个迭代所完成的开发任务，以及哪些开发任务出现了bug，哪些任务的开发时间超过了估算，分别都是什么原因，然后几个人一起商量制定一些措施去规避类似的情况。

这个版本的迭代评审会开了有小半年，然后大家就发现了这个评审会比较吊诡的情况：迭代过程中出现的问题最后都会变成开发人员的锅，然后TL（TechLead）会根据自己的观察给出一些解释，到最后就变成了TL（TechLead）代表开发人员与BA（业务分析师），QA（测试工程师）的论战。这样的情况持续了几个迭代之后，TL（TechLead）就收到了大家的反馈，大家认为TL（TechLead）将自己定位成了开发人员的代言人，人为的在团队里建立起了部门墙。

另外一个影响就是，因为迭代评审会的内容是不对开发人员公布的，评审会上总结的原因开发人员也不知道，定义出来的改正措施开发人员也无从得知，最后的改进效果就可想而知了。后来参加迭代评审会的几个角色都觉得，这个迭代评审会继续这么开下去不是个办法，如果我们的改进措施需要全体成员一起努力去推进，我们就不应该将开发人员这个团体排除在外。于是在一次讨论过后，我们将迭代评审会的范围扩大到了团队的全体成员。没成想，这个迭代评审会一开就更热闹了，迭代评审会直接开成了甩锅大会。

版本二：甩锅大会

会议的议程还是由QA（测试工程师）制作前一个迭代的迭代报告，报告里列出了所有的开发任务，工作在开发任务上的人，估算的开发时间，实际的开发时间以及每个开发任务出现bug的情况。当开发人员第一次看到这个报告的时候，我相信他们心里都是咯噔了一下的。大家互相看了看彼此，气氛一度非常尴尬。随后，伴随着QA（测试工程师）的一句“xxx，你这个开发任务估算时间是3个点，实际做了5天半，你给大家解释一下原因呗”，会议的气氛顿时达到了高潮。开发人员说做这么久是因为任务的测试场景有变化，QA（测试工程师）又解释说测试场景的变化是因为验收标准不清晰，BA（业务分析师）辩解称自己的验收标准已经很清晰了，是开发人员自己没有仔细看某个文件夹下的标准文档，场面一度失控。

开完这个会，大家的体验都非常的不好，所有人都觉的自己工作的价值受到了挑战。于是又催生出了一个新的会议形式：吐槽大会。

版本三：吐槽大会

在吸取了前面甩锅大会的教训之后，团队重新明确了迭代评审会的目的，评审会并不是为了要挑战任何一个小伙伴，因为作为敏捷团队我们相信大家都已经尽了全力。于是评审会的关注点从个人变成了整个团队。因为如果具体的挑战某个人，一般被挑战的那个人都会据理力争，但是如果挑战的是这个团队，而大家也都是这个团队的一员，从感情上好像没有之前那么的难以接受。

于是在会上大家根据自己的观察，提出了对团队合作以及工作流程上的诸多改进意见。然后大家经过一轮的商量，制定了对应的改进措施，分给不同的小伙伴去跟进。

乍一看问题仿佛得到了圆满的解决，但是紧接着大家就发现了新的问题。首先是大家发现这个评审会的内容跟另外一个迭代回顾会似乎有很大程度的重合，都是对前一个迭代的团队合作和工作流程的反思和改进，于是团队里出现了要将这两个会议合并的呼声。其次是时间的问题，因为沿袭了之前会议的时间，迭代评审会一直是在迭代的第一天回顾上一个迭代的内容，于是大家对于迭代的边界都感觉到模糊不清，迭代也没有了节奏感。但是一时之间大家也没有想清楚问题到底出在哪里。直到两位小伙伴参加完CAC的培训之后，回到团队开始了一个全新版本的迭代评审会：脑暴大会。

版本四：脑暴大会

经过一番引经据典的考证之后，团队对迭代评审会进行了新一轮的改进。首先，重新定义了迭代评审会的会议时间，迭代评审会和迭代回顾会的会议时间由迭代初的第一天改到了迭代末最后一天的下午，于是大家开始可以感觉到一个迭代结束的明显信号。其次，重新定义了迭代评审会的会议流程，先是由一位团队成员（轮流主持）将当前这个迭代所完成的全部开发任务逐一的给大家进行演示，演示的过程中会逐一的检查验收条件和测试场景，演示过程中出现的问题，以及演示过程中发现的功能缺失的部分，都会有专门的团队成员进行记录。之后PM会展示一个迭代的燃起图，大概的说明当前迭代完成的任务点数和趋势。最后，大家一起查看一下产品的用户增长情况，以及产品的各个功能被用户使用的情况。

这一版本的迭代评审会开下来，大家的感觉都非常的好。

首先，按照此前的工作流程，QA（测试工程师）会在测试完成之后关闭开发任务。可是这些功能完成得是否符合PO（产品负责人）的要求就不得而知了，而现在，PO（产品负责人）可以在每个迭代结束之前检视开发任务的完成情况，对PO（产品负责人）而言意义重大。

其次，开发人员在开发过程中往往只关注自己开发的部分，对于其他开发人员所开发的功能其实是没有概念的，通过这个评审会，他们可以俯瞰整个迭代开发出来的所有功能，对于他们而言，这是一个难得的了解全局的机会。

再次，通过查看产品功能的使用情况，可以让团队获取到用户的使用数据，如果某个功能频繁的被用户使用到，大家会感到满满的成就感，如果某个功能上线之后一直少有人问津，大家便会一起反思当初排定优先级的时候，或者用户采访的过程中，到底是哪里出现了问题。

最后，在查看迭代交付的产品特性的过程中，大家往往会发现之前设计产品时遗漏的功能特性，大家笑称这一阶段是脑洞大开，这个过程中发现的缺失功能，对于产品设计的逐步完善也能起到极大的促进作用。

以上便是我们团队的迭代评审会经历的四个版本，现在，大家逐渐的找到了迭代的节奏感，也从用户数据和互相肯定中收获了工作的成就感，大家一致认为团队的敏捷实践正在往好的方向改进。

我想说，敏捷实践我们永远在路上，希望在不久的将来我们的迭代评审会还能演进出第五个更好的版本，到时候再来跟大家分享。