使用看板进行Sprint评审
“评论家们的好评论只是另一种暂缓”——达斯汀·霍夫曼
我一直对Scrum团队进行Sprint评审的不同方式很感兴趣。我并不是在指导一系列技术，并建议团队选择他们喜欢的任何形式。我通常的指导斗争是将Sprint评审的实践规范化。
你看，Sprint评审是许多团队最不愿意考虑的事情。到迭代结束的时候，他们经常还有未完成的工作亟待任务板的关注。在这种情况下，准备和召开另一次“Scrum会议”所需的时间通常不被视为优先事项。此外，我们必须克服人类掩饰和最好忽略任何明显的失败或潜在的耻辱来源的欲望。例如，在Sprint Planning中做出的预测可能是错误的，在每个Daily Scrum中重新计划的机会可能没有得到应有的重视。任何对冲刺目标的承诺都可能在很久以前就随着晨露蒸发了。
哪个头脑正常的团队会想要回顾上次Sprint的遗憾故事，包括未完成的工作、未解决的依赖、未实现的希望和不慎重地实现的雄心?Sprint评审充其量只是对不可能设定的目标和无法实现的承诺进行令人沮丧的反思。在最坏的情况下，Sprint评审可能会吓坏一个团队，就像来自19世纪海军规则手册的虐待狂惩罚。“我们为什么要让这样可怕的野蛮行径发生在我们自己身上?团队成员低声嘟囔着。在他们看来，通过故意准备Sprint评审，他们正在打结并交出他们将被鞭打的鞭子。
这很难说是正确的敏捷精神，Scrum Master的最大挑战往往在于指导团队将每个Scrum事件视为一个重要的事件检查和适应的机会。在Sprint评审的情况下，目的是检查增量——无论它处于何种状态——并根据不断发展的业务条件调整产品Backlog。它是对已经完成的工作的回顾，也是对尚未完成但仍应完成的工作的回顾。不应该隐藏责备的潜台词。相反，通过考虑与产品负责人和被邀请的涉众一起完成的未完成和剩余的工作，就有机会重新计划待办事项，以在未来获得最有利的结果。
即便如此，当组织变化缓慢时，这些都可能听起来很空洞，而避免和分配指责仍然被视为一项重要的管理技能。事实上，根据我所看到的判断，Scrum团队想要抛弃Scrum并采用看板的主要驱动力是他们希望避免不得不接受Sprint评审的痛苦和场面。通常情况下，这就是它背后的原因。转换到基于流程的工作方式的潜在价值似乎根本没有在等式中占多大比例。考虑到团队将不再尝试在复杂的产品环境中有节奏地实现重要目标，在降低严重风险的能力方面也不会有任何损失。这也很难被描述为正确的敏捷精神。
看板有时被认为是一个软选项，因为“流”被误解为“交付的东西就交付”。一个团队将从它现在正在做的事情开始。没有必要进行冲刺。讨厌的“冲刺目标”和“冲刺Backlog”中人为的工作预测都被抛弃了。看来这支球队再也不能受制于命运了。在看板中，没有关于计划Sprint结果的大谎言，并且假定没有像达摩克利斯之剑那样悬在团队成员头上的大承诺。可怕的Sprint评审有什么用呢?相反，当每个项目完成时，产品负责人应该进行一系列的小型评审。
小型的回顾是有用的和及时的，而且它们都很好。然而，事实上，一个专业的看板团队不会逃避严肃的承诺，也不会寻求这样做。首先，它的成员需要理解和定义承诺点在他们的工作流程中。这是当他们清楚地承担一个工作项目的责任，并保证按照处理时间和质量的明确策略完成它。看板团队可能会向涉众阐明“服务水平期望”，例如，其中一定比例的项目将在一定的时间框架内完成。
一旦看板的严密性成为焦点，抛弃Scrum框架的想法似乎就不那么有吸引力了。这不是软选项。该团队将对他们提供的服务负责。实际上，团队成员可以期望像他们设定利益相关者的期望一样定期和确定地承担责任。也许还是需要一个Sprint Review之类的东西……通过这一活动，像SLEs这样的活动被检查和改编，没有指责或怨恨，通过这一活动，最近的团队经验可以采取行动，或至少可以考虑到。
因此，不一定要用看板取代Scrum，而是要在Scrum中实现看板策略。这样做可以在复杂和不确定的环境中支持和加强Scrum的经典应用。在基本的层次上，这可能意味着优化流程以更好地实现常规的Sprint目标，例如交付一个重要的特性，围绕这个特性，Sprint Backlog预测可能以受控的和工作受限的方式伸缩。
Sprint目标的关键在于，它必须给团队成员一个在Sprint期间一起工作的理由，而不是在不同的计划上分道扬镳。令人惊讶的是，看板的常规实现实际上是可能的。请记住，在Scrum中，对“产品”的理解是相当广泛的，它很可能等同于服务的供应。在某些sprint中，目标可能是提供并满足商定的SLE，而在其他sprint中，传统的特性风险缓解可能更重要。在Scrum中，冲刺目标可以是任何连贯且有价值的功能结果。团队可以合理地选择关注于改进工作流程，而不是特定特性的交付。Sprint评审可能从SLE开始，然后从此转向周期时间、最大工作项年龄、观察到的任何服务类别和吞吐率。产品待办事项列表可以被调整以更好地支持期望的结果，例如将项目分解成更小的价值单位。对已完成项目的蒙特卡罗分析也可以成为讨论的主题，因为它可以告知团队他们未来应该做出的承诺。
综上所述，Scrum团队执行Sprint评审的格式可以与工作本身和预期结果一样多样。如果团队成员一直专注于特性交付，那么一些新功能的“演示”可能是活动的重点。如果重点确实更多地放在流程上，那么重点可能会放在服务水平期望和任何相关的生产指标上。然而，Sprint评审的正确格式可能介于两者之间。在使用看板实现Scrum时，有许多可用的选项。重要的是首先要认识到举行Sprint评审的不可简化的目的。