印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。

如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而这种休整并非是将团队成员集体拉出去＊＊一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期间，队医的×××、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。

敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。Scrum对于回顾有一个主要指导原则，这也是敏捷回顾的“最高指导原则”：
 
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。

——敏捷回顾之“最高指导原则”

听起来，有些像一团和气的“和稀泥”做法，这样的原则会否让回顾会议的参与者一个个都变成好好先生呢？难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异。

坦白说，我反对在进行团队成员评价时，采用这么一条“最高指导原则”，但这样的看法已经偏离了***的靶子了。需要知道，“最高指导原则”是应用在敏捷回顾中，而敏捷回顾的最终目的是学习，而不是绩效评审活动[1]。

如果敏捷回顾没有确定这条“最高指导原则”，用来倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，忘记了我们召开回顾会议的初衷。“最高指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之，或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“最高指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该是“对事不对人”。

我曾经在一个项目的回顾会议上，听到了测试经理对于某开发小组产品质量的评价，认为该小组开发的模块出现了太多的bug。经过回顾会议的认真分析，最后得出的结论是该小组Leader迫于进度压力，因而盲目地追求开发进度，却忽略了保障代码质量的单元测试覆盖率。于是，我们仔细讨论了下一次Sprint的 Sprint Backlog，根据团队成员的能力进行了合理的分配。果然，在下一次Sprint中，该小组开发的模块出现的bug率降低了差不多50%，即使bug总量并不大，这样的比例仍然是非常可观的。而且，由于项目组成员都明白回顾会议的原则，因此并没有产生团队成员之间的不快，开发人员和测试人员仍然能够合作得非常愉快。

在《Scrum Checklists》中，指明了Scrum回顾会议的议程：
1、在白板上写上主要指导原则；
2、在白板上画上一个至少三页纸连在一起长的时间轴；
3、在白板上写上“我们的成功经验是什么”；
4、在白板上写上“有什么能够改进”；
5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。

从以上的步骤可以看出，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给与团队成员更大的信心，并能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。

在项目中持续改进至关重要。所谓“取其精华，去其糟粕”，唯有如此方能够去芜存菁，提高敏捷团队的战斗力。每一个敏捷团队都不可能是十全十美的，要么是在技术上存在个体差异，要么就是缺乏足够的领域知识，或者，还未曾找到符合团队现状的开发方法（即使采用敏捷方法，也需要因地制宜，切忌生搬硬套。即使现在符合，也不等于永远符合，即使符合这个项目，却未必符合下一个项目。敏捷方法不可能放之四海而皆准）。即使这些均已具备，那么团队成员之间的磨合也并非一朝一夕之功。若没有持续改进，团队就会像生锈的刀刃，不仅会褪去摄人的光芒，还会逐渐钝化腐朽。

在项目过程中，有一个原则是处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都炼就“火眼金睛”。在会议中，我们经常会发现，一旦某个成员发现了一个问题，接踵而来的就是每个成员都会发现一大堆问题。

发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。

此外，《敏捷回顾——让团队从优秀到卓越》一书的作者Esther Derby在接受InfoQ的采访时，还提到：“使用回顾来解决冲突问题。他们在每个迭代中都进行检视、实验，并构建解决冲突的技能和信心。随着时间推移，他们学会了如何处理每个团队都会发生的“平常的”冲突。当大家意见出现严重分歧时，他们有能力、也有信心在团队内部解决问题。而且更有利的是，由于他们可以在团队内部解决全部问题，他们的经理就可以花费更多的时间来消除组织中对团队造成的障碍。当然，这使得团队能够轻装上阵，以更加轻松的心态来开发软件。”[2]

现在，在你的项目团队经历了一次艰难的迭代之后，你需要休息一下以等待灵魂的到来么？那么，就请尝试一下敏捷回顾会议吧，或许你会从中得到意想不到的收获。

参考文献：
[1] Linda Rising，敏捷回顾活动“最高指导原则”答疑解惑
[2] Deborah Hartmann，图书节选：敏捷回顾——让团队从优秀到卓越