Sprint评审的误区 | 真不是演示会 demo show

Scrum旨在作为用于复杂产品交付的简单但足够的框架。 Scrum并非万能的解决方案，灵丹妙药或完整的方法论。相反，Scrum提供了最小的边界，团队可以在这些边界内使用经验方法自组织解决复杂的问题。这种简单是其最大的优势，同时也是围绕Scrum的许多误解和误区的来源。

误区：Sprint评论是一个演示

又到了冲刺评审的时候了。开发团队正在其中一间会议室中进行演示。当Jim将笔记本电脑连接到投影仪时，Susan紧张地重新整理了团队完成当前Sprint的工作记录。 “我要展示新的购物车吗？”她问高级开发人员约翰，声音有些不确定。约翰点了点头，然后停顿了一下，加入购物车“。然后，我将显示新的订单审核页面”。随着时钟调到11点，利益相关者开始进到会议室，笨拙地在巨大的桌子周围找到位置。产品负责人马丽到达，并在桌头的一种更舒适的椅子上坐下。她转向开发团队并发出Sprint评审开始的信号； “散会”。四十分钟后，开发团队评审了已完成项目的清单，并展示了所有值得展示的内容。随着演示的结束，观众向开发团队致以热烈的掌声。当利益相关者离开会议室时，开发团队松了一口气。 “嗯，这是一次很棒的Sprint评审！”马丽总结道。

在这篇文章中，我们解决了一个误区，即“Sprint评审”主要是一个将增量“演示”给利益相关者的机会。

如果您意识到以下的迹象，则适合您：

• 利益相关者很容易与开发团队区分开，都占据了自己的房间；
• Sprint评审是采用Powerpoint演示文稿，其中包含(据说)软件的屏幕截图；
• 在场的利益相关者均未实际使用或打算使用该产品；
• 利益相关者几乎没有任何投入(或者没有邀请他们参加)；
• 在Sprint评审期间，用于点击产品的键盘和鼠标实际上从未交到利益相关者、用户的手中，但在开发团队中却无可挑剔。
• 演示结束后会鼓掌。更糟糕的是，开发团队被嘘出了房间。
• 开发团队普遍有紧张感；
• Sprint团队和利益相关者实际上将Sprint评审称为“演示”；

通过将Sprint评审主要作为演示来对待，失去了进行检查和调整的重要机会的目的。太多的Scrum团队将Sprint评审作为展示进度，提供“产品更新”，向利益相关者出售所构建产品或谈论他们所做的事情的时刻。

“太多的Scrum团队将Sprint评审作为展示进度，提供’产品更新’，向利益相关者出售产品或谈论他们正在做的事情的时刻。”

Sprint评审的目的

《Scrum指南》的描述作为“在Sprint结束举行以检查增量和调整产品待办事项列表的事件”的Sprint评审。”。这强调在Sprint评审期间，“ Scrum团队和利益相关者就Sprint所做的事情进行协作。基于此以及在Sprint期间对产品待办事项列表所做的任何更改，与会人员将就可为实现价值最大化而进行的下一步工作进行协作。”

“在Sprint评审期间，Scrum团队与其利益相关者之间的合作至关重要”

换句话说，在Sprint评审期间，Scrum团队与其利益相关者之间的合作至关重要。在Scrum中，我们了解到产品开发是一项复杂的活动。在进行工作时，我们要解决的问题和最佳解决方案都会从我们在开发过程中所学到的知识中浮现出来。 Sprint评审是Scrum中的关键机遇，它可以通过让已完成的工作中产生见解并在其基础上为后续步骤提供意见来使其成为可能。

Sprint评审旨在使产品的状态(增量)和产品待办事项透明。然后，Scrum团队和利益相关者对这两者进行检查，并分享从该检查中学到的知识。连同当前的市场状况，组织变更，预算和时间表，他们共同决定下一步。 Sprint评审的输出包括根据所学知识对产品待办事项进行的调整。从某种意义上说，Sprint评论旨在回答以下问题：“根据我们学到的Sprint的知识，下一步是什么？”这为Sprint计划提供了宝贵的意见。

好的Sprint评审具有以下特征：

• 利益相关者和开发团队的成员与局外人是无法区分的；
• 积极邀请参与者提供反馈、建议和想法；
• 产品待办事项在Sprint评审中占有重要位置，并随着新见解的出现而积极调整；
• Sprint评审不是将开发团队向产品负责人介绍增量，而是整个Scrum团队(包括产品所有者)与利益相关者分享增量；
• 产品负责人讨论产品待办事项，并根据进度传达可能的完成日期；

• 在开始之前，请重申Sprint评审的目的。请确保人们了解此次活动是关于收集反馈并共同解决复杂问题，而不是“销售产品”或“接受已完成的工作”；
• 要求开发团队成员与利益相关者“结对”并一起检查增量。不要让开发人员在平板电脑，笔记本电脑或台式机上演示增量，而是将键盘/设备交给利益相关者，让他们在开发人员的指导下进行实验；
• 避免使用Powerpoint或屏幕截图检查增量状态。实际操作软件是验证开发人员、用户和其他利益相关者的假设和解释的最佳方法。
• 确保所有开发人员都参加Sprint评审。 Sprint评审是一个理想的机会，可以在Sprint期间收集有关开发人员改进/规模化/更新的产品反馈。最好的情况是，Sprint评审是与真正参与Scrum团队进度并渴望看到和讨论结果的利益相关者一起进行的一次活动。
• 使用有效的格式，不要坐在桌子旁看着屏幕。使用引导技巧让所有参与者积极参与。
• Sprint评审应该是一个“反馈方”，而不是开发团队在其他人都昏昏欲睡时浏览“完成的工作”清单。
• 邀请真实用户参加Sprint评审。这些是(将)实际使用产品的人员，最有能力确定产品是否“效果良好”。不过，请尽量避免将Sprint评审转变为“用户接受测试”；
• 更改格式。根据上下文更改Sprint评审的格式。有时，最好设置不同的“市场摊位”，在这些摊位中，开发人员会设置为突出产品的特定方面。有时，集中演示并随后进行便利的讨论最为有效。 Scrum团队应不断寻找从利益相关者那里收集反馈的最佳方法；
• 在闭幕式中，请参与者根据进展如何做(进一步)提高Sprint评审的价值；
• 通过电子邮件，新闻通讯或个人邀请各种方式来邀请参加者，说明参加者为何如此重要的原因；
• 对未完成的工作要公开透明。并非所有的Scrum培训师都同意，共享未完成的工作是一个好主意。因为这可能会产生错误的期望。但是我们认为，检查未完成的工作可以产生宝贵的见解。它可以告诉我们一些有关障碍，瓶颈或其他问题的信息。在Sprint评审期间着重于确定这些问题，但将其解决方案留给Sprint回顾；

在这篇博客文章中，我们打破了“Sprint评审”是关于将增量增量演示给利益相关者的误区。尽管演示当然可以成为Sprint评审的一部分，但它无法捕获Sprint评审的真正含义：Scrum团队和利益相关者之间的合作，以检查迄今为止的增量和进度，并确定最有价值的下一步。

• 你的Sprint评审是如何进行的？
• 有邀请利益干系人吗？
• 您如何看待这个误区？
• 您是否认识到Sprint评论不仅仅是一个演示？
• 您学到了什么？

欢迎留言讨论。