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评论不仅仅是一个演示？
  • 您学到了什么？

欢送留言探讨。

本文首发于 Bob Jiang的博客 ，转载请分割 Bob Jiang