Bruce有话说
回顾会是Scrum中重要的一个Event，也是比较难做好的。因为她是一个团队践行透明、检视、调整三大支柱的一个过程。需要团队自身能够调整好心态，做到有勇气刨析自己，抱着开放的心态，尊重每个人的想法。当然这种刨析更多的是抱着积极的心态去探索和寻找优点和可以改进的地方。
最近和一个团队一起工作，切实感受到了团队的成长和变化。回顾会从一开始不知道说什么，到大家主动发言来说出可以改进的方向，自信的表明自己做得好的方面。这些变化让我感触良多，对团队的变化深深的感动，当然也有作为敏捷教练的小小成就感。
今天我们来一起读一下Scrum Patterns中的Sprint回顾这一模式。一起学习一下做好团队回顾都要关心哪些地方。下面总结几个对我很有感触，并能在本文中得到的答案的要点，希望对小伙伴们阅读本文有帮助：
- 每日站会也是团队每天的调整的场所，他和回顾会的作用有什么不同？
- 回顾会是从一个sprint的整个过程中，并从团队的系统层面来讨论并考虑改进。
- 回顾会是团队自己的空间，尽量避免团队以外的人参加，尽量创造安全氛围。
- 在开过几次回顾会后，团队开始怀疑已经做的很好了没有需要改进的地方了。这会发生吗？
- 遵守时间盒子，避免团队产生厌烦和无聊情绪。
- Product owner是否要参加回顾会呢？
- 回顾会也不是万能灵药，要配合其他事情来做改进。
- 如何避免团队在回顾会上的负面情绪。
正文
你即将到达当次Sprint的终点，并为下一个Sprint做好准备。当然，无论事情进展得多好，你都想要改进她。
✥ ✥ ✥
随着时间的推移，如果没有明确的关注，过程和纪律往往会消亡。人们会变得越来越随意。在没有适当的聚焦的情况下进行孤立的过程改进会带来熵增，而如果没有周期性的改进，团队就会错过增加价值的机会。
你想要不断提高。每日Scrum让团队有机会检查自己，并在每天的基础上改进产品方向。但是，由于一些原因，它不是一个适合重新规划过程改进的场合。
首先，在工作效能上每天都有变化，对正常的过程做出调整是没有意义的。一天(从一个Daily Scrum到下一个Daily Scrum)往往太短，无法看到一个改变是否真的能带来预期的改进，而在Sprint中改变流程充其量也只是破坏性的。其次，每日Scrum的重点是检查和调整以实现Sprint目标。因此，视野是非常短期的，开发团队专注于完成其迭代内的工作，而不会去关注团队系统级的问题。第三个原因是，在激烈的战斗中期(在Sprint的中间阶段)，你可能只会得到一个或两个问题的观点，而不是对大多数影响因素的充分认识。团队从不完整的信息中得出结论是危险和不恰当的。
在Sprint评审中，团队与干系人一起评审产品。这个Scrum事件不是分析问题和提出改进建议的场合，而应该只关注产品本身。开发团队和产品负责人作为一个自组织团队应该对这些问题有主人翁意识，并决定如何在Sprint评审之外，没有干系人的情况下改进它们。Sprint评审中聚焦产品，围绕一次性问题召集团队和干系人。然而，在Scrum中更重要的是探索那些导致问题的循环出现的模式，这些问题看起来是独立的和不相关的，但实际上却很少是这样。
由于Sprint一个接一个地进行，所以人们倾向于从一个Sprint跳到下一个Sprint，很少或根本不考虑团队如何完成(或完不成)工作。这会导致反复做同样的事情，犯同样的错误。
在对比之前的sprint做了一些改进之后，Scrum团队可能会认为他们已经做得很好了，没有新的改进需要发现(“这就是我们工作的方式!”)。改进的附加价值似乎在下降，因此团队可能会回顾是在浪费时间(“我们已经非常忙着在做真正的工作了!”)。
当一个团队审视自己时，它会使其成员容易受到批评。个人可能会感到尴尬、威胁或无能为力。这可能导致防御性行为，在这种行为中，团队成员可能会否认他们自己的责任，无论是个人还是集体，并使问题外化([1])。
因此：
每次Sprint结束时，都要有一个事件，让Scrum团队可以评估他们在Sprint期间是如何执行工作的。
在Sprint结束时举行一次Sprint回顾。这是一个自然的反思时间。检查完成的工作揭示了一个完整的系统视角(其中系统是团队及其运行过程)。在一个过程中评估一个人是如何工作的，这只能从一个非常有限的角度提供一个局部的图景。因此，我们将回顾与完成的工作在Sprint范围内结合起来。此外，这个时候对Sprint的挑战和胜利的原因仍然在每个人的脑海中记忆犹新。
为了实现最大价值，团队提出过程改进。这些改进可以与人、关系、过程、环境或工具有关。
✥ ✥ ✥
Scrum起源于以流程改进为核心的丰田生产系统(TPS)。在TPS手册中，我们找到了这样的说明:“检查是关于Hansei。”“Hansei”是对失败的个人或集体深深的遗憾。优秀的Scrum团队在失败后会使用hansei，然后将对失败的遗憾转化为解决问题的正能量;参见Scrumming the Scrum。因此，Sprint回顾也是团队恢复和更新的时机。精益社区认为大野耐一是TPS的创始人。人们常说他的一句名言是:
没有人比声称自己没有麻烦的人更麻烦。(没有问题是最大的问题。)[2]
专注于发展团队文化，使Sprint回顾成为每个Sprint的组成部分。将其融入到团队的常规节奏中。避免因为感觉需要时间来完成上一次Sprint的工作而跳过Sprint回顾。因为这将强化回顾并不重要的文化信念。
使用会议时间盒。留出足够的时间去深入探索问题，但不要让时间过长而让大家感到无聊。Scrum建议一个月的Sprint会议不要超过3小时。Sprint越短，会议时长就越短。
通常情况下，整个Scrum团队都应该参加，包括产品负责人。在极少数情况下，如果开发团队成员觉得产品负责人主导了谈话，或者压制了坦率和公开的讨论氛围，他们可能会要求产品负责人不要参加。请注意，这可能是一个更大问题的迹象。因为Scrum是一个帮助解决问题以实现更大价值的框架，而且产品负责人是价值主张的核心，产品负责人的可信参与是超越任何表面衡量的长期成功的关键。
敏捷宣言[3]的其中一个原则是定期进行回顾：
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
回顾，特别是定期安排的回顾，很容易变成不探讨实质性问题的肤浅会议。为了解决这个问题，可以使用已知的有效的回顾方法，例如在[4]中编目的方法。例如，一种方法是确定进展顺利的事情、正在进行的问题和要做的具体事情([5]，[6])。考虑不时地改变回顾方法。基于以往经验思考的讨论。尤其可以检查这些具体的指标，如Sprint Backlog完成的百分比和团队速率。此外，确定团队在下一个Sprint期间将进行的具体过程改进。
优先级排列在障碍列表中的改进计划。模式“One Step at a Time”建议团队一次只做一个更改，这样他们就可以理解每个更改如何对改进做出贡献；参见Scruming the Scrum。幸福度量模式建议拥抱变化，这将最能最大限度的提高团队的热情和参与感。另外，确保你可以度量改进带来的好处和负担：它的成本、优点和缺点(请参阅可测试的改进)。
坚持进行Sprint回顾并不能保证过程的改进，甚至过程的稳定性。虽然仅仅做回顾是不够的，但定期关注改善思想可能是必要的(参见kaizen和Kaikaku)。如果做得好，Sprint回顾会起到鼓励团队的作用，并让他们为能够随着时间的推移对改进感到骄傲;看到产品的自豪感。
回顾很容易沦为抱怨的会议。为了解决这个问题，在回顾会上遵循Norm Kerth提到的主旨:“不管我们发现了什么，我们都理解并真正相信每个人都尽了自己最大的努力，考虑到他们当时所知道的，他们的技能和能力，可用的资源，以及手头的情况”(“回顾练习”[6]的第六章)。这需要像community of Trust中描述的那样的群体。同时，让团队意识到他们自己可以改变什么，在短期内不能改变什么，或者根本不能改变什么([7])。此外，要识别好东西(“金砖”)和问题。不要只往坏处看。有些好的东西可能值得写下来。例如，当团队发现并学习到实现“完成”某个任务的新技术时，书面的“完成定义”就会不断增加(参见“完成定义”)。抱怨也可以表明更深层次的问题，ScrumMaster应该关注回顾事件整体基调中更深层次问题的线索。
注意，仅仅两三个小时的回顾通常不足以探索深层次的问题。因此，Sprint回顾是讨论深度和会议长度之间的一种折衷。在Sprint回顾中发现的问题可能是由于更深、更复杂的关系，团队不能在短短三小时内恰当地揭示和探索这些关系。根据Jeff Sutherland在与投资集团的交流后总结一份经验报告中指出:
障碍就像蚊子。你杀了一个，会飞来25个。所以，你需要找到根本原因。你要做的就是排干沼泽的水，让蚊子不再来。
为了“排干沼泽”，你可以考虑按照Swieringa和Wierdsma ([8]， pp. 37-42)所描述的在双环甚至三环学习的水平上工作。简而言之，单环学习就是改变规则，双环学习就是改变基本结构。三环循环学习涉及组织的基础和历史的基本原则和价值观。Norm Kerth建议用三天的时间来探索组织中的深层结构问题，他还提出了一个为期三天的非现场回顾框架，以推动这一级别的改进([6])。Kerth回顾的更广泛的应用更适合处理团队的深层漏洞，因为它比相对较短的Sprint回顾投入了更多的时间在团队成员之间建立信任。它还允许在增量改进之外进行更深层次的kaikaku(不连续)改进，增量改进通常是Sprint回顾的重点。
Skype视听工程团队负责Skype的高质量音频和视频，同时也负责编解码器的开发，他们偶尔会举行两到三天的非现场会议，以配合他们的团队sprint。这些活动引领了新的发明，重新设计了他们自己的工作空间，以及开发过程的创新。［9］
[1] Chris Argyris. “Teaching smart people how to learn.” Reflections 4(2), 1991, https://www.ncsu.edu/park_scholarships/pdf/chris_argyris_learning.pdf (accessed 2 November 2017).
[2] Taiichi Ohno. AZQuotes, Taiichi Ohno Quotes, http://www.azquotes.com/author/44597-Taiichi_Ohno, n.d., (accessed 11 July 2018).
[3] —. Manifesto for Agile Software Development: Principles. Agilemanifesto.org, http://agilemanifesto.org/principles.html, 2001, accessed 23 January 2017.
[4] Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Raleigh, NC: Pragmatic Bookshelf, 2006.
[5] Alistair Cockburn. Agile Software Development, 2nd ed. Reading, MA: Addison-Wesley, Oct. 2006.
[6] Norm Kerth. “How long should a retrospective be?” In Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001, ff. 53.
[7] Stephen R. Covey. The 7 Habits of Highly Effective People Simon & Schuster, 1992.
[8] Joop Swieringa and André F. M. Wierdsma. Becoming a Learning Organization: Beyond the Learning Curve. Reading, MA: Addison Wesley, 1992, pp. 37–42.
[9] Personal communication with Mark Gillett, former Skype COO, 22 February 2019.
Picture credits: Image from: M.C. Escher’s “Hand with Reflecting Sphere” © 2018 The M.C. Escher Company-The Netherlands. All rights reserved. http://www.mcescher.com.
