关于SegmentFault:敏捷误区Sprint评审的误区-真不是演示会-demo-show

2次阅读

共计 2850 个字符，预计需要花费 8 分钟才能阅读完成。

Scrum 旨在作为用于简单产品交付的简略但足够的框架。Scrum 并非万能的解决方案，灵丹妙药或残缺的方法论。相同，Scrum 提供了最小的边界，团队能够在这些边界内应用教训办法自组织解决简单的问题。这种简略是其最大的劣势，同时也是围绕 Scrum 的许多误会和误区的起源。

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

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

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

利益相关者很容易与开发团队辨别开，都占据了本人的房间；
Sprint 评审是采纳 Powerpoint 演示文稿，其中蕴含 (据说) 软件的屏幕截图；
在场的利益相关者均未理论应用或打算应用该产品；
利益相关者简直没有任何投入(或者没有邀请他们加入)；
在 Sprint 评审期间，用于点击产品的键盘和鼠标实际上从未交到利益相关者、用户的手中，但在开发团队中却无可挑剔。
演示完结后会鼓掌。更蹩脚的是，开发团队被嘘出了房间。
开发团队广泛有紧张感；
Sprint 团队和利益相关者实际上将 Sprint 评审称为 ” 演示 ”；

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

“ 太多的 Scrum 团队将 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 回顾；