敏捷圣贤：其实，你们不需要准备一个非常华丽的演示，只需要展示你们刚刚完成的最新功能即可。不需要额外修饰，只要让人印象深刻，就已经足够了。总之，这不是一个产品发布会，你不需要创造一个非常炫目的演示。
阿捷：但是，如果某些小组成员的工作不能直接通过软件演示怎么办？他们会感觉被排除在演示之外的。
敏捷圣贤：不要仅仅从字面上理解“演示”这两个字，范畴可以更广一些。这里的“演示”，还可以是对下列事情的回顾：如一个新建的wiki网页、某人新写的小工具、一份说明文档或其他任何具体的可以让该团队感觉到有价值的东西！
阿捷：嗯，这样就好办多了。我还担心如果涉及性能测试怎么办呢。看来我们只需要把我们做的性能测试对比结果展示给参加人员就可以了。
敏捷圣贤：非常正确，加十分！ 据我的经验，演示要安排在Sprint回顾会议之前。此外，更重要的是要让这个演示会议充满乐趣，不能搞成批斗会。
阿捷：我想我们可以准备一点小食品、饮料什么的，把它搞成一个庆祝会议，这应该是一个团队建设的好机会。
敏捷圣贤：非常好的想法。记得在每个人做完演示后，都让大家集体鼓掌庆祝。
阿捷：好的，我想我们会开好Sprint 评审会议，做好演示的。那么回顾呢？它的主要价值是什么？
敏捷圣贤：嗯，先不着急！你听说过印第安人灵魂的故事吗？
阿捷：啊，印第安人？灵魂？是个什么样的故事？恐怖吗？
敏捷圣贤：呵呵，又不是给你讲鬼故事，你怕什么？是这样的，从前，有个古老的传说，讲的是当印第安人在赶了3天路后，就会停下来小憩一天，因为他要等着自己的灵魂跟上来。这跟敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，是一个意思。我们也需要等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。如果将项目开发比作是一次征途，那么在项目中期进行短期休整是很有必要的。
第7章 镜子反射（3）
阿捷：我知道了！就是将团队成员集体拉出去*一次，或者K歌去，或者爬山、郊游去，目的是让大家放松一下。 我们现在每个月都有一次这样的活动，大家都很Enjoy的。
敏捷圣贤：这些是可以的，但不是必要的，因为这些都只能带来身体的休息与放松。
阿捷：这不是最重要的吗？那还有什么别的？
敏捷圣贤：你看很多运动员在比赛间歇期，会有队医给他按摩，有人帮他擦汗，有人给他喝饮料解渴。这些重要吗？当然重要，这的确可以让他们放松疲惫的身体，保持充沛的体力，通过短暂休整获得能量。但更重要的是灵魂的“反刍”，需要教练员针对其在上一局比赛的表现，给出盘点，分析他及对手的优与劣，给出具体战术指导，帮助制定出针对后面比赛的对策，方能最终击败对手，赢得比赛。
阿捷：嗯。
敏捷圣贤：Sprint回顾会议与平常我们经常提到的项目总结会议不同，它不是要对项目进行盖棺定论，而是通过及时回顾，总结上一次快跑中的得与失，找到改善与提高的办法，从而让下一个Sprint走得更好。
阿捷：那该怎么做Sprint回顾呢？
敏捷圣贤：也很简单，关注两点就可以了。第一点是找出在上一个Sprint中做得好的地方，并继续保持。分析那些导致成功的流程是非常重要的，这样我们才能有意识地保持下去。只有团队中的每一个成员都清楚什么才是最佳实践，才能有效地鼓励和保持这些实践。除了可以鼓舞士气外，还可以避免把回顾会议变成消极的抱怨会议。第二点是找出上一个Sprint中需要改进的地方，以及对应的改进措施。回顾的目标就是持续不断地改进，这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个Sprint中更加有效率，想一想在哪些方面如何做才能跟上一个Sprint不同。可以收集任何可以量化的数据，以便于做定量分析，推动改善。
阿捷： 还有其他一些什么事情是要特别注意的？
敏捷圣贤：首先，一定要明确这样一个最高指导原则。即“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴”。
阿捷：啊哈！听起来，就是“和稀泥”的做法啊！这样的原则应该会让回顾会议的参与者都变成好好先生的。难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异？
敏捷圣贤：对团队成员的绩效评估，当然不能采用这样的指导原则。我们现在谈论的是Sprint回顾，回顾的最终目的是学习，而不是审判。如果敏捷回顾没有确定这样的“指导原则”，倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，脱离了我们召开回顾会议的初衷。
阿捷：嗯。
敏捷圣贤：“指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该“对事不对人”。
阿捷：嗯，这一点的确很重要！我们以前开项目总结会议时，总被美国同事揪小辫子，搞得大家都很不舒服！谁会是真的想故意捣蛋呢？
敏捷圣贤：是啊！人们总是容易犯常识性的错误。
阿捷：有什么好的方法来组织这个回顾会议？你上次给了我如何开好Daily Scrum站立会议的8个指导原则，对我帮助非常非常大！
敏捷圣贤：其实，组织Sprint 回顾的最简单方法是找个白板纸，在上面注明“哪些项工作顺利”，“哪些项不成功”或者“哪些项可以做得更好”，然后让与会者在每一类别下增加一些条目。当条目重复时，可以在该项旁边计正字累计，这样普遍出现的项目就一目了然了。最后团队成员共同讨论，找寻这些条目出现的根本原因，就如何在下一个 Sprint 中改进达成一致意见。
阿捷：嗯，很简单很直观。
敏捷圣贤：张瑞敏不是说“能够把简单的事情天天做好，就是不简单！”吗？其实，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给予团队成员更大的信心，并且能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。
阿捷：嗯，我们一定会重视敏捷回顾会议的，我相信一定会从中得到意想不到的收获。
敏捷圣贤：嘻嘻……我这个老师还不错吧？
阿捷：那当然。你怎么发了个嘻嘻？怎么跟MM似的？
敏捷圣贤发过来一个鬼脸，外加一个886，就下线了。阿捷自己寻思，这人真怪，说话怎么神神道道的，难道世外高人都这样？阿捷没有多想，还是赶紧总结一下的好，能够跟高人过招并从中学习是多么宝贵的一次经历啊！阿捷把总结写入自己的Blog后，才放心地去睡觉。
电子书 分享网站
第8章 我烧，我烧，我烧烧（1）
Attained with more support； and enjoys little support。
得道者多助，失道者寡助。
——《孟子》
这天上午，阿捷他们正在开Daily Scrum站立会议，老板Charles走了过来！似乎有什么事情，但为了保证自己团队的站立会议不受外人的打扰，阿捷仅仅礼貌性地点了点头，示意大家继续。
阿捷暗想，根据Scrum规则，我们正在开会的这些人，都是真正参与到当前这个Sprint的人，都是有mitment的！换句话说，我们都是“猪”，而其他人只能是旁听者，充其量就是“鸡”了。所以即使是老板来，也不能破坏这个规则。作为一个团队的Scrum Master，要真正承担起“牧羊犬”的角色，要保护自己的团队不受外来打扰。没办法，即使你是老板，在这会儿，你也得到一旁凉快去！
Charles也还识趣，不仅没有打断大家，还饶有兴趣地站在一旁听起来。看到老板没有打断大家，阿捷不禁得意起来。
还好，今天的会议只花了8分钟，因为项目进行得很顺利，大家也没有提出任何阻碍团队向前快跑的问题。也就不需要在每人说完后，再单独开一个解决问题的短会了。
“你们现在是每天都开这个会议吗？”还未等阿捷开口，老板已经率先发问了，很显然，憋了这么半天，对于一直强势的Charles来说，还是从来没有的事情。
“嗯，是啊！这样我们能够随时地沟通，及时地解决问题。”阿捷有点忐忑不安，不知道老板葫芦里面卖的什么药。
“这是你自己的感觉呢？还是大家的？”
“我们大家都这么认为的！”
“你们白板上画的图是作什么用的？”老板指�