Sprint回顾大揭秘——“宝典”来了

我始终记得当年我做为敏捷教练所作的第一次Sprint回顾，这一切都仿佛就发生在昨天。这家公司实行Scrum有好几年了，我天然而然地认为他们这群人是纪律严明而且成熟稳重的敏捷专家。

所以，当他们计划了一系列Sprint回顾会议，用来展现X团队最新Sprint成果时，我感到异常兴奋。我早早地溜进了会议室，并为本身找了个绝佳的位子坐下，翘首以盼。

渐渐地会议室里的人愈来愈多，并变得嘈杂起来，这反而使个人指望到达顶点，我知道好戏就要开演了。这时，第一个团队登上了“舞台”，准备他们的回顾，他们打开PowerPoint作的幻灯片，“演出”终于开始了！

 

第一个团队准备的材料实在是精挑细选，他们准备了在这个Sprint中他们所完成的事情的列表，还配了插图，甚至还准备了些在适当时刻调节气氛的小笑话。他们一一讲述团队所作的工做，一页接一页地翻动着幻灯片，在恰当的时机，听众也不失时宜地礼貌地鼓掌以表示对他们的赞许。

然而，当第一场回顾进行到一半的时候，我意识到彷佛有很是、很是重要的东西被遗漏掉了，怎么没有代码演示呢？我心中感慨，这样的错误怎么会发生在这样一群成熟且经验丰富的敏捷专家身上呢？整个Sprint回顾的最终目的就在于向各位利益相关者展现这个Sprint所完成的代码，并获得你们的反馈。当时我想，也许这只是一个特例，只是被这个团队疏忽了，接下去确定会有代码演示。

然而，我期待的事情并无发生，以后的每个团队使用着跟第一个团队相同的模式——风趣幽默的幻灯片和文字，对他们的工做量进行说明，并无代码演示，这让个人热情迅速耗尽， 也让我完全失望。

相关厂商内容

Droid Plugin如何实现免安装运行第三方插件APK？

在容器时代，云计算下一步将如何发展？

ArchSummit8折优惠期，节省1360元/张！

 

相关赞助商

全球架构师峰会，12月18-19日，北京·国际会议中心，8折报名。

 

对于整个团队而言，还有那些诠释过Sprint回顾意义的人而言，显而易见地是，他们并无真正理解Sprint回顾的意义。固然，利益相关者也没能理解这么作的目的，他们仍然对那些设计好的笑点礼貌地回应，并鼓掌确定团队的工做，彷佛这个仪式仅仅是为了给Scrum流程列表上的这一项打上个勾而已。

千万杜绝！

在此后的Sprint回顾中，毋庸置疑的是，我不再会让这类事情发生了。我很敬佩这些团队的自主精神，但我仍然当即列出了从此Sprint回顾应该完成的目标以及如何实现这些目标的纲领。

纲领中的某些项目跟敏捷宣言（Agile Manifesto）很是合拍，例如在每一个迭代或Sprint结束时进行代码演示的理念，但有些项目倒是咱们的组织以及企业文化中特有的。

这才是文章的重点。我打算与你们分享，咱们当时是如何转变Sprint回顾的主要纲领、战略以及心态的，正如：

• 从礼节性地鼓掌转变到热烈地欢呼
• 从礼节性地鼓掌转变到得到有建设性的反馈
• 从兜售咱们的成果转变到让成果变成真实透明
• 从小众群体参与转变到大众站立方式并运用录影
• 从幻灯片转变到代码演示
• 从娱乐大众的心态转变到展现团队能力及产品价值
• 从“授课”形式的演示转变到有交流、有互动的形式
• 从刻意兜售咱们的成果转变到“姜太公钓鱼，愿者上钩”、让事实说话的形式

固然，冰冻三尺非一日之寒，这些不会立刻发生，咱们仍然在日复一日持续对咱们的Sprint回顾进行着调整和优化。幸运的是，咱们当真找到了一些门路，使之成为贯穿组织架构中实施敏捷流程的基础。 让我来分享几件咱们用心作的事情吧。

“出色”的Sprint回顾

整体来讲，我认为Sprint回顾很是重要，之因此这么说是由于：

1. 一个敏捷团队为世界上最重要的故事（story）专心工做了一段时间，并准备交付与之相关的功能或故事。单从这点上看，回顾就足够重要，人们的目光都汇集在这里，你们渴望见到成果，因此你必须知足你的“观众”。
2. 团队有义务展现他们的工做成果，但这不仅仅停留在代码演示，团队应该站出来说述围绕他们的工做所发生的故事。这能够是图文并茂的，伴有情节的，并且这必须与上一次的Sprint回顾有联系，并对下一次的Sprint回顾作出铺垫。

接下去我将为你们分享Sprint回顾的7个最重要的方面以及一个简单的回顾会议日程。我但愿这些建议能帮助你们改进你的Sprint回顾，能更有效地拉拢你的利益相关者，并更全面、更充满激情地展现你的团队。

Sprint回顾的7招绝杀

1. 职责
   在每次Sprint回顾中，咱们都会创建起一种产品负责人对此全权负责的理念。诚然，这是每一个团队成员的事情，但在天天工做结束时，产品负责人会负责进行外部沟通、展现计划中所交付的代码，以及对收集到的反馈意见进行相应地调整。他们还负责把你们找来作回顾——若是与会者良莠不齐，人数稀少（小众参与），他们就必须找到问题所在并作出相应改变，让“合适的”人聚到会议室里进行Sprint回顾（大众站立式）。 我时常把产品负责人比做典礼的主持人——他们负责引导Sprint回顾的各个方面。固然他们不须要事事亲历亲为，但他们须要把握整体的回顾质量，考虑回顾的重点以及对回顾的成果负责。

2. 形式
   咱们对回顾的日程安排以及时间控制出了不少主意（若是你置身于多个Sprint团队，那么也能够是多个Sprint的回顾）。你确定但愿你的回顾具备固定的节奏（时间与间隔），在进行Spring内容回顾时，你也确定但愿每一个团队都听从统一的流程（以后的章节将给出回顾会议日程安排的例子）。 在咱们的案例中，因为咱们有多个Sprint，而且是同步的，咱们在同一天演示多支团队的成果，所以咱们的回顾形式有一种跨团队的平常安排，将3个小时的回顾会议合理地分配给每一个团队。咱们不只对每一个团队的回顾作出安排，更重要的是，咱们的首席产品负责人对每一个团队的回顾流程进行统一的节奏掌控。

3. Sprint目标
   就我的而言，我更倾向于Sprint回顾主动地去契合团队成员都认同的Sprint目标。我常常嘱咐个人团队，当他们在制定Sprint目标的时候，多想想如何撰写他们须要发送的回顾邀请邮件。这个Sprint的故事就会契合Sprint目标，团队成员也将采起相应的行动来达到Sprint目标。

   另外，你必须对团队所要承诺的Sprint交付物100%的诚实，你必须告诉你们成功了或是失败了。但千万不要让“失败”这个词把你们都吓坏了，失败乃成功之母，它是团队自我学习的一部分，也是整个组织保持一种“向失败学习，不被其战胜”的积极态度的重要组成部分。

4. 人人参与
   正如我所说，我崇尚把产品负责人看成整个典礼的主持人，那么Scrum Master则是协调者（若是须要的话），而整个团队才是真正的大明星。给予你的团队成员一个表现本身的机会，让他们站出来展现他们的成果。人人参与的方式，将给予你的团队足够的表现空间——让团队成员轮流地去作代码演示，这样一来，每一个人都有机会为你们演示本身的劳动成果。

   但必须记住，不要强迫性格内向的成员去作大范围的演讲，你能够鼓励每一个团队成员去表现，但这必须不是强制性的。一般，性格内向的成员能够成为演示的参与者，他们是很好的聆听者，安静地参与回顾。可是，你必需要鼓励团队的每一个成员积极参与回顾。

5. 准备 若是说什么是成功的Sprint回顾秘诀，那就是以前的准备工做了——别放太多的内容，也别过于简单了，把握好这个度。你必须去思考，什么内容是和此次Sprint回顾相关的；回顾应该以怎样的流程进行下去；你还要去想，此次回顾如何与前一次，后一次的回顾相互呼应。

   一般，有着质量保障（Quality Assurance）背景的人会提早写一个回顾的“脚本”，帮助本身更紧凑地揭示工做成果。但最终，产品负责人才是决定回顾哪些内容，以及为何作这些回顾一槌定音的人，他为利益相关者搭建好回顾的“舞台”。

   若是有疑问，在Sprint计划阶段就给回顾的准备留出足够的时间，并认真地去作准备。

6. 执行与演示 你须要保证整个回顾演示必须是顺畅的、有思想的、精心商榷的，而且最终的软件是能够无差错地工做。你须要执行试运行（Dry-running）演示，并确保全部代码环境都事先调试经过。你还必须计算好演示的时间，保证不会超过预留给你的时间，同时也不要忘记提问部分。

   除了演示，你最好能描述一下你所开发的功能特性或工做流。我曾见过一些团队在他们的第一次Sprint回顾中就给出了他们在将来6次Sprint所规划的工做的架构图。在此后的每一次Sprint回顾，他们只需作作简单的“填空游戏”就能把他们的应用程序架构附上“皮肉”（意指代码实现）。我以为这是一种很是好的方法，可以帮助回顾会议的听众涉点及面。

   在我看来，团队在一个Sprint中涉及的全部工做均可以在Sprint回顾中被展现，这包括：功能特性、功能改进、Bug修复、重构、文档、测试架构等等，任何工做均可以放进来。固然有些东西可能要等到必定的程度才能拿得出，但只要是团队作的，均可以成为回顾的内容之一。

   最后，考虑好如何描述清楚你的演示，让你的听众可以理解你所演示的内容，内容的关键部分，以及团队在这些内容背后的辛苦付出。

7. 总结 最后，咱们老是对两个方面进行回顾总结——软件自己的反馈意见以及回顾会议的反馈意见。例如：这个过分是否平稳？全部人都明白咱们作的东西了吗？你清楚如何向咱们提供反馈意见了吗？下一次回顾有什么地方须要改进吗？咱们一般都会在这个阶段花上几分钟，但这几分钟绝对超值！若是你对举手表决（Fist-of-Five）的理念比较熟悉的话，咱们一般使用这个方法来结束反馈过程。

回顾会议日程安排举例

你能够考虑将如下做为你的团队Sprint回顾会议日程安排的模板：

1. 介绍

2. 组织架构

   • 团队成员角色：名字、角色、工做地点等
   • 对Sprint提供帮助的外部成员

3. 工做承认——感谢

   • 这个绝对是团队成员的出彩时间
   • 这也是对Sprint提供帮助的外部成员的工做进行承认的好时机

4. Sprint目标

   • 阐明Sprint目标，以及有何调整
   • 宣布Sprint是否成功，团队成员是否兑现承诺

5. 战略目标、成功定义、工做量、新发现、成果

   • 分享团队交付的代码所考虑到的总体战略目标
   • 围绕Sprint幕后的工做量
   • 是否有考虑不周全的地方；关键的成果
   • 全部这些都为回顾会议的听众提供了一个了解团队Sprint幕后故事的机会

6. 演示、提问时间

   • 演示所选择的用户故事集以及功能特征——接受提问

7. 将来议项

   • 宣布现行目标的进程以及将来Sprint所涉及的工做

8. 回顾改进意见的举手表决（Fist-of-Five）

   • 鼓励回顾会议的听众对团队的表现进行反馈
9. 结束

总结

我没法用语言表达一次高质量的Sprint回顾将带给你何种感觉，这须要你亲身去感觉。尽管产品负责人及团队很大程度地左右着回顾成果，但做为敏捷项目的项目经理，你一样扮演着相当重要的角色。 一般，团队成员在努力工做时被抓出来，仓促地准备Sprint回顾。事实上，这么作是典型的反例。你必须在Sprint计划时就嘱咐团队留出相应的时间给Sprint回顾，而且在Sprint即将完成的时候，善意地提醒他们，作好Sprint回顾的准备工做。

请记住，这个回顾会议也是团队能力的一个“质量检查点（QA Checkpoint）”。将各项工做放在一块儿并演示出来，无疑是提升团队Sprint能力的最佳途径了。你每每会发现——环境没有准备好、整合没有作好或者交互没有实现等等诸如此类的麻烦事。

所以，各位敏捷项目的项目经理们，我但愿这篇文章可以影响大家，使大家发生转变，把Sprint回顾作成敏捷实现中最有利的一种手段，真正担当起Sprint回顾的重任。虽然团队才是作准备及完成交付的人，但你的任务是去影响他们进行回顾的态度与方式。随着项目的进行而不断的进步，你能够将你能得到的正向反馈无限放大，帮助你的团队更好地完成敏捷项目。