下载掌阅APP，畅读海量书库
立即打开
周一阿捷跟李沙一起，用Excel整理了一份Product Backlog，不仅列出了所有的用户故事，还让李沙对它们进行了优先级排序。阿捷按照敏捷圣贤的建议，提前把计划会议日程发给大家，让大家能有所准备。周二，阿捷召开了第二个Sprint计划会议，只用了三个小时。因为事先准备充分，效果好多了，大家的心气又给聚起来了！
在对每日站立会议进行了改进后，平均每天只花10分钟就能结束了！大家相互沟通了信息，问题得到了及时解决，会议效率提高了，大家都很满意。
周末的晚上，阿捷再次遇到敏捷圣贤，阿捷决定向他请教一下如何开好Sprint评审会议和回顾会议。
阿捷： 嗨！你好！
敏捷圣贤： 你好！心情不错！
阿捷： 是啊！当前的这个Sprint，我们的计划会议开得非常好，不仅请了Product Owner，还让他起草了最新的Product Backlog，而且对Sprint中的任务进行了细化，给出了大家一致认同的DONE的定义。同时，按照你的建议，我们对Scrum每日站立会议做了改进。现在，每个人都能总结性地回答四个问题，这样一般10分钟左右就能结束会议，效率比以前高多了！
敏捷圣贤： 恭喜你们！
阿捷： 谢谢！这次多亏了你的建议呢。我们上次说要讨论一下Sprint的演示与回顾，还记得吗？
敏捷圣贤： 嗯，当然记得。作为Scrum Master，回顾并总结一个刚结束的Sprint所做的工作，是非常有价值的，这就像镜子反射！
阿捷： 镜子反射？
敏捷圣贤： 对，每个人出门前都要照镜子，目的是什么？
阿捷： 哦，我不照镜子的。
敏捷圣贤： 别捣乱。目的有二：一是看看自己穿的衣服怎么样，化的妆怎么样，是不是得体；二是看看哪些方面还需要修整（如衣服的扣子扣得是否合适、穿的衣服是否合体，等等），以更利于展示自己最漂亮的一面。
阿捷暗想，这哥们儿真够逗的，还说化妆呢，难道还真的每天出门前照镜子？因为还不够熟悉，阿捷没表露出来，接着回复道：你的意思是作为一个团队，也应学会“照镜子”，要时时发扬自己的优点，找到自己的不足，及时加以改正。
敏捷圣贤： 对！孺子可教也。
阿捷： 不过，我有这样一个疑问！发生的已经发生了，都已经过去了！如果说一个团队，刚刚结束一次冲刺的话，每个人都很累，为什么非要揭开旧伤疤，让大家再次痛苦呢？
敏捷圣贤： 暂时的痛苦可以让你在未来的日子里过得更好，避免犯同样的错误。让我们先来看看评审会。你是怎么理解的？
阿捷： 我看了一些资料，在Scrum中，评审会是说在一个Sprint 结束以后，进行Sprint 评审，团队在此期间展示他们所完成的工作、可运行的软件。参加评审的应该有Product Owner、开发团队、Scrum Master，加上客户、项目管理者、专家和高层人士等任何对此感兴趣的人。
敏捷圣贤： 不错，还有吗？
阿捷： 会议可以是10分钟，也可以持续两个小时。因为会议目的只是对所做工作结果的展示，并听取反馈。
敏捷圣贤： 嗯，说得挺全面的。
阿捷： 我还是不想让我的团队，在Sprint快结束的时候花很多时间到演示上，实际上，他们可以做很多真正有意义的事情。为什么我们要浪费力气演示我们刚刚做过的工作？我们的目标不就是一个可以随时交付的软件吗？我们的目标已经完成了，就摆在那里。谁感兴趣，看看我们的Sprint Backlog就可以了啊。
敏捷圣贤： 这是一种常见的误解。其实呢，演示主要是出于这样几个目的：
演示可以让那些虽然不直接参与Sprint的利益相关者，获得你们这个团队工作的最新进展。这里提到了利益相关者，就意味着你可以随意邀请任何没有直接参与Sprint工作的人，只要相关。
演示可以让客户或者Product Owner对你们所做的工作提供最直接的反馈，这样可以让Scrum 团队，根据反馈更新产品Backlog，在下一个Sprint中融入新的需求变化，并将这些反馈带到下一个Sprint的计划会议上。
同时，演示是一个很好的机会，可以让团队庆祝他们在过去的Sprint中所取得的成就，鼓舞团队的士气。
阿捷： 嗯，听上去好处多多。但准备一个演示，是要花费很多时间的。
敏捷圣贤： 其实，你们不需要准备一个非常华丽的演示，只需要展示你们刚刚完成的最新功能即可。不需要额外修饰，只要让人印象深刻，就已经足够了。总之，这不是一个产品发布会，你不需要制作一个非常炫目的演示。
阿捷： 但是，如果某些小组成员的工作不能直接通过软件演示怎么办？譬如性能测试、架构或者代码的重构等等。
敏捷圣贤： 不要仅仅从字面上理解“演示”这两个字，范畴可以更广一些。这里的“演示”，还可以是对下列事情的回顾：如一个新建的编辑页面、一个新写的小工具、一份说明文档或其他任何具体的、可以让该团队感觉到有价值的东西、或者是你们工作过程的截图等！
阿捷： 嗯，这样就好办多了。我还担心如果涉及性能测试怎么办呢。看来我们只需要把我们做的性能测试对比结果展示给参加人员就可以了。
敏捷圣贤： 非常正确，Just Show Proof（展示证据即可）！加十分！据我的经验，演示要安排在Sprint回顾会议之前。此外，更重要的是要让这个演示会议充满乐趣，不能搞成批斗会。
阿捷： 我想我们可以准备一点小食品、饮料什么的，把它搞成一个庆祝会议，这应该是一个团队建设的好机会。
敏捷圣贤： 非常好的想法。记得在每个人做完演示后，都让大家集体鼓掌庆祝。
阿捷： 好的，我想我们会开好Sprint 评审会议，做好演示的。那么回顾呢？它的主要价值是什么？
敏捷圣贤： 嗯，先不着急！你听说过印第安人灵魂的故事吗？
阿捷： 啊，印第安人？灵魂？是个什么样的故事？恐怖吗？
敏捷圣贤： 又不是给你讲鬼故事，你怕什么？是这样的。有个古老的传说，讲的是印第安人在赶了3天路程后，都会停下来小憩一天，因为他要等着自己的灵魂跟上来。这跟敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整是一个意思。我们也需要等待团队的“灵魂”跟上来，这一过程被称之为“敏捷回顾”（Agile Retro）。如果将项目开发比作是一次征途，那么在项目中期进行短期休整是很有必要的。
阿捷： 我知道了！就是将团队成员集体拉出去腐败一次，或者K歌去，或者爬山、郊游去，目的是让大家放松一下。我们现在每个月都有一次这样的活动，大家都很期待的。
敏捷圣贤： 这些是可以的，但不是必要的，因为这些都只能带来身体的休息与放松。
阿捷： 这不是最重要的吗？那还有什么别的？
敏捷圣贤： 你看拳击运动员在比赛间歇期，会有队医给他按摩，有人帮他擦汗，有人给他喝饮料解渴。这些重要吗？当然重要，这的确可以让他们放松疲惫的身体，保持充沛的体力，通过短暂休整获得能量。但更重要的是灵魂的“反刍”，需要教练员针对其在上一局比赛的表现，给出盘点，分析他及对手的优与劣，给出具体战术指导，帮助制定出针对后面比赛的对策，最终击败对手，赢得比赛。
阿捷： 嗯。
敏捷圣贤： Sprint回顾会议与平常我们经常提到的项目总结会议不同，它不是要对项目进行盖棺定论，而是通过及时回顾，总结上一次冲刺中的得与失，找到改善与提高的办法，从而让下一个Sprint走得更好。
阿捷： 那该怎么做Sprint回顾呢？
敏捷圣贤： 也很简单，关注两点就可以了。第一点是找出在上一个Sprint中做得好的地方，并继续保持。分析那些成功的流程是非常重要的，这样我们才能有意识地保持下去。只有团队中的每一个成员都清楚什么是最佳实践，才能有效地保持这些实践。除了鼓舞士气外，还可以避免把回顾会议变成消极的抱怨会议。第二点是找出上一个Sprint中需要改进的地方，以及对应的改进措施。回顾的目的是持续不断地改进，这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个Sprint中更加有效率，想一想如何做才能与上一个Sprint不同。收集任何可以量化的数据，以便于做定量分析，推动改善。
阿捷： 还有其他一些什么事情是要特别注意的？
敏捷圣贤： 首先，一定要明确这样一个指导原则。即“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及现状，我们理解并坚信：每个人对自己的工作都已全力以赴”。
阿捷： 啊哈！听起来，就是“和稀泥”的做法啊！这样的原则应该会让回顾会议的参与者都变成好好先生的。难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，为了团队利益而抹杀团队成员之间的个体差异？
敏捷圣贤： 对团队成员的绩效评估，当然不能采用这样的指导原则。我们现在谈论的是Sprint回顾，回顾的最终目的是学习，而不是审判。如果敏捷回顾没有坚守这样的“指导原则”，倡导团队成员首先要信任自己的伙伴，已经尽了最大努力，就会让回顾会议成为互相攻击、互相推诿的批斗大会，脱离了我们召开回顾会议的初衷。
阿捷： 嗯。
敏捷圣贤： “指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图寻找到最佳实践以避免在下一次迭代中犯同样的错误，而“指导原则”则能够消除因为指出他人错误时给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该“对事不对人”。
阿捷： 嗯，这一点的确很重要！我们以前开项目总结会议时，总被美国同事揪小辫子，搞得大家都很不舒服！谁会是真的想故意捣蛋呢？
敏捷圣贤： 是啊！人们总是容易犯常识性的错误。
阿捷： 有什么好的方法来组织这个回顾会议？你上次给了我如何开好Daily Scrum（每日立会）的8个指导原则，对我帮助非常非常大！
敏捷圣贤： 其实，组织Sprint 回顾最简单的方法是找个白板纸，在上面注明“哪些项工作顺利”“哪些项工作不成功”或者“哪些项工作可以做得更好”，让与会者在每一类别下增加一些条目。当条目重复时，可以在该项旁边画正字累计，这样普遍出现的条目就一目了然了。最后团队成员共同讨论，找寻这些条目出现的根本原因，就如何在下一个 Sprint 中改进达成一致意见。
阿捷： 嗯，很简单很直观。
敏捷圣贤： 张瑞敏不是说“能够把简单的事情天天做好，就是不简单”吗？其实，敏捷回顾的主要目的就是明确目标、持续改进和处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给予团队成员更大的信心，并且能够更加清晰地明确目标。而每次迭代后的回顾，使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。当然，也可以用ORID（Objective Reflective Interpretive Decisional，焦点呈现法，一种沟通引导方式），结合‘心情曲线’、4F、4R等玩法，要让你的回顾会多样化，避免形式上的千篇一律。另外，地点的选择也可以多样化，不一定总是在公司会议室开，可以去咖啡厅、水吧，甚至是公园的草坪，团队建设的饭桌上。关键就是要灵活多变。
阿捷： 嗯，我们一定会重视敏捷回顾会议的，我相信一定会从中得到意想不到的收获。
敏捷圣贤： 嘻嘻……我这个老师还不错吧？
阿捷： 那当然。你怎么发了个嘻嘻？怎么跟MM似的？
敏捷圣贤发过来一个鬼脸，外加一个再见，就下线了。阿捷寻思，这人真怪，说话怎么神神道道的，难道世外高人都这样？阿捷收回思绪地自言道：“还是赶紧总结一下的好，能够跟高人过招并从中学习是多么宝贵的一次经历啊！”
1. Sprint评审会议不是让开发团队做成果“演讲”：会议上不一定要有PPT，最好是直接做产品演示。会议通常不需要超过30分钟的准备时间，只是简单地展示工作结果，所有与会人员可以提出问题和建议。
2. 在Sprint评审之后，开发团队会进行Sprint回顾。有些开发团队会跳过此过程，这是不对的，因为它是Scrum成功的重要途径之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用，而什么不起作用，就改进的方法达成一致。
3. Scrum开发团队，Product Owner和Scrum Master都将参加会议，会议可以由外部中立者主持；一个很好的方法是由Scrum Master互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
4. 敏捷回顾不能是一场没有主题的讨论会，这样的形式对于项目进展没有任何帮助。
5. Scrum回顾会议的参考议程。
· 在白板上写上主要指导原则。
· 在白板上画上一个至少三页纸连在一起长的时间轴。
· 在第一页上写上“我们的成功经验是什么”。
· 在第二页上写上“有什么能够改进”。
· 在第三页上写上“谁负责”，然后分成两个区域，分别是“团队”和“公司”。
6. Scrum回顾会议的指导原则。即“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及现状，我们理解并坚信：每个人对自己的工作都已全力以赴”。
7. 在项目过程中，问题处理得越早，那么付出的代价与成本就越小。通过回顾会议，利用团队成员互相善意地“敲击”，或者反复“锤炼”开发过程与方法，就能够让每一位成员练就“火眼金睛”。
8. 进行Scrum回顾时，发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定责任人和处理时间，一定要SMART。
9. 在每个Sprint开始的时候，我们都要明确，当Sprint结束的时候需要演示的是哪些东西。很多时候，如果一个Scrum开展得不是很顺利，在Sprint演示的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有的，我只需要改动小小一点东西就可以了”，或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到”。如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除拒绝通过这些相关的需求之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint演示会议上看到什么东西。强调我们重视的是可交付的软件版本，而不是一个口头上的功能实现。
10. 回顾会议要灵活多变，可以采用ORID技术，结合心情曲线、4F和4R等玩法，一定要让你的回顾会多样化！
评审会议与回顾会议
评审会议的目的是获取相关人员的反馈，是迭代进度展示，同时给业务方，以及高层领导以信心（这点很重要，要想清楚谁是团队的投资人），是团队进行阶段成果展示以及进行庆祝的机会，“鸡类”角色与“猪类”角色都要参与。评审的目的是获取反馈，回顾的目的是学习改进。
演示并不是评审会议中最重要的一环，更重要的则是审视，调整计划以适应当前的情况。
两个会议都是仪式感的体现，是每个Sprint不可或缺的。两个会议纪要都应该有专人记录，并通过邮件公开发出，如果有可能，通过工具记录在本Sprint的信息中。
两个会议都是必要的，如果两者一定要比较，我认为回顾会议会更重要一些。评审会是针对业务层面的，面向结果的；回顾会是针对团队层面的，是面向过程的；磨刀不误砍柴工，从长期来讲，持续的学习和改进，最终对业务输出会产生根源的影响。科恩（Mike Cohn）说：“有时，我以为衡量一个团队敏捷实施质量的最好标准是看他们对待回顾会议有多认真。”
另外的一个例证是，关于回顾会议，有专门的一本《敏捷回顾》来讲如何开回顾会议，而评审会议则没有专门的图书。
安全度检查
回顾会议中，最重要的是要能听到真话，要为团队成员创造一个敢于畅所欲言的氛围，即安全感。
安全度检查，是回顾会议中很容易被忽视的一个环节。安全度检查，是将安全性从“愿意畅所欲言”到“想保持低调”分成几个不同的等级。会议开始时，所有团队成员将其自身感觉所处的等级，匿名写在一张纸片上，折好交给会议组织者。由组织者统计安全度。如果等级都比较高，回顾会议可以继续开；如果有较低等级出现，哪怕是个别人，会议组织者需要考虑是否取消本次会议，或者采取一些措施，让大家放松下来，直到安全等级都比较高以后，再进行会议。
如同Blameless Post Mortem（无指责的事后分析会议），关键是营造安全的氛围和文化。每个人都不用担心自己会承担风险，可以自由地表达意见，并提出不会被评判的问题。需要提供一种保护文化，使团队成员可以畅所欲言，大胆尝试。在这里，管理者起到至关重要的作用。
安全文化的营造，也与学习型组织和个人成长型思维等密不可分。
持续改进
回顾会议是Scrum中进行检视与调整的一个重要的环节。
会议应该面向未来，而不是简单的对过去进行回顾，回顾主要的目的还是为了改进。改进不宜太过贪心，建议每个人针对每个方面，不超过三条，但不能一条不写。如果安全度较低，也可以尝试不记名的方式。针对提出的问题，可以用计点投票法，得票高的三个问题进入讨论环节。可以进行头脑风暴，进行五指表决法等；对回顾会议输出的改进点，可以统一维护到产品Backlog，作为特殊类型的需求，与技术故事对应的技术债务一样，流程也存在债务，需要定期偿还；团队可以决定每个迭代固定做多少比例的流程改进故事，多少比例的技术故事。回顾与改进，应该变成团队承诺，每个迭代，都必须有所改进，积少成多，聚沙成塔。
此外，回顾会应该尽量保证会议聚焦，并且高效；但偶尔举行大团队的回顾会也是有益的，可以保证在更大范围内获取改进建议和经验分享；这类会议开销较大，通常以季度为周期即可。
回顾会议也有一些小的游戏环节，例如心情卡片，用一个词形容你现在的感受；或是感谢环节，每个人通过写卡片的形式感谢他人对自己的帮助，或是对团队做出的贡献。
________________________
________________________
________________________