Sprint

什么是Sprint?

与其它Scrum事件不同，Sprint并不是一个会议，而是Scrum团队为实现Sprint目标而完成的所有工作的容器。Daily Scrum、Sprint计划、Sprint评审和Sprint回顾都包含在Sprint中，还包括产品待办事项的细化。

在Scrum中没有工作是在Sprint之外进行的，并且Sprint之间也没有间隔。当一个Sprint结束时，下一个Sprint立即开始。每个Sprint以计划会议（Sprint计划）开始，以对Sprint期间完成的工作的评审（Sprint评审）和对Sprint过程的回顾（Sprint回顾）结束。在Sprint过程中，开发人员每天开会（Daily Scrum）以审查他们朝着Sprint目标的进展。

为了支持Scrum快速反馈循环的原则，Sprint的持续时间不应超过一个月。

让你的Sprint更高效

Sprint的目的、时间盒和参与者都有明确的定义。然而，我们看到Scrum团队有时会陷入一些反模式，从而削弱了它们的价值。

常见的反模式包括：

• 不断地将工作从一个 Sprint 转移到下一个Sprint – 没有计划好工作以适应Sprint周期的团队，会发现自己不得不将工作推到下一个Sprint中。
• 频繁改变Sprint长度 – 随着产品的演进，可能需要延长或缩短Sprint。然而，频繁改变Sprint的长度可能表明团队在希望减少会议频率（如Sprint计划、Sprint评审和Sprint回顾）和他们意识到需要更频繁地从利益相关者那里获得反馈之间摇摆不定。
• 专门的Sprint – 专门的Sprint（如设计、分析或测试Sprint）通常表明团队对Scrum的理解存在问题。例如：
  • 有些团队创建了一个“Sprint 0”，即项目正式开始前的一个Sprint。当团队建议有一个Sprint 0时，可能是因为他们觉得必须创建一些工件（如产品待办列表和完成的定义），或解决一些程序或技术问题（如开发产品时使用哪些工具）。然而，Scrum的本质是从复杂问题入手，并逐步迭代解决它们。没有所谓的“Sprint 0”，它只是一个“Sprint”。
  • 有些团队创建了一个“强化”Sprint，专注于提高产品质量。如果团队认为有必要进行一个“强化”Sprint，往往是因为他们在创建、发展和遵守他们的完成定义方面不够用心。他们通常承担了太多的工作，没有时间创造高质量的结果。不应该有“强化”Sprint。相反，在早期的Sprint中，完成的定义可能不那么严格，随着时间的推移，完成的定义可能会变得更加严格，迫使后期的Sprint具有更高的质量期望，而不是突然创建一个Sprint来纠正质量问题。
• 将Sprint作为小型瀑布项目运行 – Sprint的开始用于解决方案开发。接近Sprint结束时，所有的工作都进入测试阶段。
• Sprint开始时将整个Sprint待办列表标记为“进行中” – 团队经常使用看板来可视化每个Sprint待办事项的状态。至少，这些状态是“待办”、“进行中”、“阻塞”或“完成”。当开发人员在Sprint开始时选择他们打算工作的PBI并将它们全部标记为“进行中/进度中”时，就会产生这种反模式。

实现强大Sprint的建议：

为了实现强大而有效的Sprints，可以考虑以下建议：

• 两周的Sprint可能是确定Sprint长度的一个良好起点。如果无法将产品待办项变得足够小以适合两周的Sprint，或者无法定义可以在两周内实现的Sprint目标，则考虑延长Sprint。较短的Sprint是有益的，因为它们提供了更频繁的反馈和调整机会。
• 尽量保持Sprint长度的一致性。有时团队会在假期期间增加Sprint的长度，通常是为了在整个Sprint中保持“速度”的一致性。然而，速度是衡量价值创造的一个较差的标准。团队应该简单地在高缺勤率期间减少预期的工作量。