印第安人的灵魂——敏捷回顾（转）
如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而这种休整并非是将团队成员集体拉出去腐败一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期间，队医的按摩、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。
敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。Scrum对于回顾有一个主要指导原则，这也是敏捷回顾的“最高指导原则”：
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。
——敏捷回顾之“最高指导原则”
听起来，有些像一团和气的“和稀泥”做法，这样的原则会否让回顾会议的参与者一个个都变成好好先生呢？难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异。
坦白说，我反对在进行团队成员评价时，采用这么一条“最高指导原则”，但这样的看法已经偏离了攻击的靶子了。需要知道，“最高指导原则”是应用在敏捷回顾中，而敏捷回顾的最终目的是学习，而不是绩效评审活动[1]。
如果敏捷回顾没有确定这条“最高指导原则”，用来倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，忘记了我们召开回顾会议的初衷。“最高指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之，或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“最高指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该是“对事不对人”。
我曾经在一个项目的回顾会议上，听到了测试经理对于某开发小组产品质量的评价，认为该小组开发的模块出现了太多的bug。经过回顾会议的认真分析，最后得出的结论是该小组Leader迫于进度压力，因而盲目地追求开发进度，却忽略了保障代码质量的单元测试覆盖率。于是，我们仔细讨论了下一次Sprint的 Sprint Backlog，根据团队成员的能力进行了合理的分配。果然，在下一次Sprint中，该小组开发的模块出现的bug率降低了差不多50%，即使bug总量并不大，这样的比例仍然是非常可观的。而且，由于项目组成员都明白回顾会议的原则，因此并没有产生团队成员之间的不快，开发人员和测试人员仍然能够合作得非常愉快。
在《Scrum Checklists》中，指明了Scrum回顾会议的议程：
1、在白板上写上主要指导原则；
2、在白板上画上一个至少三页纸连在一起长的时间轴；
3、在白板上写上“我们的成功经验是什么”；
4、在白板上写上“有什么能够改进”；
5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。
从以上的步骤可以看出，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给与团队成员更大的信心，并能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。
在项目中持续改进至关重要。所谓“取其精华，去其糟粕”，唯有如此方能够去芜存菁，提高敏捷团队的战斗力。每一个敏捷团队都不可能是十全十美的，要么是在技术上存在个体差异，要么就是缺乏足够的领域知识，或者，还未曾找到符合团队现状的开发方法（即使采用敏捷方法，也需要因地制宜，切忌生搬硬套。即使现在符合，也不等于永远符合，即使符合这个项目，却未必符合下一个项目。敏捷方法不可能放之四海而皆准）。即使这些均已具备，那么团队成员之间的磨合也并非一朝一夕之功。若没有持续改进，团队就会像生锈的刀刃，不仅会褪去摄人的光芒，还会逐渐钝化腐朽。
在项目过程中，有一个原则是处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地 “敲击”对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都炼就“火眼金睛”。在会议中，我们经常会发现，一旦某个成员发现了一个问题，接踵而来的就是每个成员都会发现一大堆问题。
发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。
此外，《敏捷回顾——让团队从优秀到卓越》一书的作者Esther Derby在接受InfoQ的采访时，还提到：“使用回顾来解决冲突问题。他们在每个迭代中都进行检视、实验，并构建解决冲突的技能和信心。随着时间推移，他们学会了如何处理每个团队都会发生的“平常的”冲突。当大家意见出现严重分歧时，他们有能力、也有信心在团队内部解决问题。而且更有利的是，由于他们可以在团队内部解决全部问题，他们的经理就可以花费更多的时间来消除组织中对团队造成的障碍。当然，这使得团队能够轻装上阵，以更加轻松的心态来开发软件。”
现在，在你的项目团队经历了一次艰难的迭代之后，你需要休息一下以等待灵魂的到来么？那么，就请尝试一下敏捷回顾会议吧，或许你会从中得到意想不到的收获。
个人理解：
要让所有普通员工都能理解并实践敏捷的理念，其实难度还是比较大的。
人都是有惰性的，我身为一个普通员工刚开始搞敏捷的时候也曾经认为敏捷是领导的事情，根本没认真的学习和感悟敏捷给我们到来的优势，这也许也算是丢了灵魂的一种吧。
一个团队需要长期的磨合才能建立起互信的关系，合作方同事多、人员流动性大也导致团队整体对敏捷的意义理解不深，再加上项目压力大，可能很多团队都是在敏捷的外衣下裸奔。
关键还是要控制好每个迭代的需求量，充分的把每一个迭代做好，否则很容易出现赶工的现象，工作效率低下，心情烦躁，抱怨因为某人进度慢而导致所有人加班，这样团队互信就很难建立了，回顾会议也就很容易就变成了批斗会。
迭代的间隙要加强对上一个迭代的总结，加强技术学习，善于在团队内交流并分享经验（可以适当的给与奖励措施，毕竟人都有自私和懒惰的一面），做好“反刍”，为下一轮的冲刺做准备。
