Scrum - 指导原则

虽然这篇文章讨论了Scrum中的一些常见指导原则，但重要的是要记住这些指南是灵活的，应根据您团队的需求进行塑造。

当我提到规则时，我指的是那些无法修补以适应特定背景的方面。例如，没有产品负责人，开发团队和Scrum Master，您就无法做Scrum。

当我提到指南时，我指的是那些可能被改变以适应特定背景的方面; 但是，影响只能在实施后进行验证。然后我们相应地检查和调整。

例如，Product Backlog细化消耗不超过团队容量的10％。容量是小时数，故事点数还是天数？嗯，没有规则。Scrum团队自我组织并选择最适合他们背景的东西; 遵循我们消耗的指导方针，不超过团队容量的10％。

在这篇文章中，我将探讨一些将11个要素绑定在一起的指南，并让Scrum团队灵活地将这些方面融入其背景中。

＃1。开发团队规模

建议开发团队的规模为3-9名成员。根据具体情况，可能会有更多人或更少。它的影响因团队环境而异。不到三个开发团队成员减少了交互，导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制，导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多的协调。大型开发团队为实证过程提供了太多的复杂性。

＃2。开发团队的标题/角色

Scrum无法识别开发团队中的任何标题/角色。在开发团队中，每个人都是开发团队成员。虽然在组织内，团队成员可能拥有头衔/角色。根据我的经验，我没有遇到任何只有一个头衔/角色的团队。

＃3。每日Scrum的三种问题格式

我使用过的大多数团队都使用了每日Scrum的三个问题的格式：

• 昨天我做了什么帮助开发团队实现Sprint目标？
• 今天我将做些什么来帮助开发团队实现Sprint目标？
• 我是否看到任何妨碍我或开发团队满足Sprint目标的障碍？

这三个问题只是以Scrum开头的团队的模板。只要他们专注于Sprint目标的进展，开发团队就可以按照他们认为合适的方式构建他们的Daily Scrum。

＃4。活动时间表

事件的时间框表示一个月Sprint事件允许的最长时间。指南是：对于较短的Sprint，时间限制通常较短。

这是否意味着，对于为期两周的Sprint，Sprint Planning的时间限制为四小时，Sprint Review为两小时，Sprint回顾为一个半小时​​？没有。

只要满足其目的，事件可以根据需要调整短/长，但它们不能超过最大分配时间。例如，Sprint计划为期两周的Sprint计划活动如果达到目的可能会在两小时内结束，如果不满足，则可能会持续八个小时。

＃5。进展趋势

Scrum指南建议使用烧毁图表和累积流量等实践来监控进度。但是，团队可以完全自由选择他们认为合适的任何练习。根据我的经验，我见过团队创建视觉路线图，基于里程碑的进度，旅程线，释放燃烧图表等。我们还需要记住，在复杂的环境中，只有经验数据才能帮助我们做出正确的决策。

＃6。估计

在Scrum的指南介绍了需要积压的产品项目来进行估计。如何估算它们完全取决于Scrum团队。故事点，理想日，T恤尺码，狗尺码是一些方法。

Scrum团队可以做“没有估计”吗？当然，只要Scrum团队能够起草支持经验主义的计划，创建透明度，并帮助团队在Sprint结束时创建可能可释放的“完成”增量。Scrum团队自行组织选择适合其背景的内容。

＃7。工作分解

在“选择的工作将如何完成？”部分下。对于Sprint计划，Scrum指南提到：

开发团队在Sprint的头几天计划的工作在本次会议结束时进行分解，通常分为一天或更短时间。

然而，这通常有助于发展团队这样做。根据我的经验，我看到几个团队没有将他们的工作项目细分到如此细致的水平。他们了解如何将功能转换为“完成”增量。

＃8。Sprint评论

这是一项重要的检查和调整活动，Scrum团队与主要利益相关方就Sprint期间取得的成果进行合作，以及在下一个Sprint中可以做些什么来优化产品的价值。

Scrum指南还描述了Sprint Review中的元素：

• 与会者包括Scrum团队和产品负责人邀请的主要利益相关者。
• 产品负责人解释了产品待办事项项目已“完成”且未完成的内容。
• 开发团队讨论Sprint期间的情况，遇到的问题以及这些问题是如何解决的。
• 开发团队演示了它“完成”的工作，并回答了有关增量的问题。
• 产品负责人会讨论产品Backlog。他或她根据迄今为止的进展（如果需要）预测可能的目标和交付日期。
• 整个小组就下一步做什么进行合作，以便Sprint Review为后续的Sprint Planning提供有价值的信息。
• 回顾市场或产品的潜在用途如何改变下一步最有价值的事情。
• 审查下一个预期的产品功能或功能发布的时间表，预算，潜在功能和市场。

对于已经获得资助一年的Scrum团队来说，在每两周一次的Sprint评审中审查其预算是否有意义？也许不吧。

并非所有上面提到的元素都适用于所有Scrum团队。它们作为指导提供，以便Scrum团队可以选择在Sprint审核期间讨论和触及产品交付的各个方面，因为他们认为适合他们的上下文。

＃9。发布到生产

每个Sprint的目的是创建一个可能可释放的“完成”增量。这意味着增量需要处于可用状态并满足Scrum团队的完成定义（DoD）。

然而，将增量释放到生产中的选择由产品负责人决定。根据团队的上下文及其创建的增量，Scrum团队可能决定每个Sprint执行多个版本，每个Sprint发布一个版本，或者累积发布多个Sprint; 无论如何优化产品的价值。

＃10。完成的定义

“完成”的定义有助于提高透明度，并对完成工作的含义达成共识。根据Scrum指南，Scrum团队有望扩大他们的国防部并使其更高质量的更严格。

同样，这不是一个规则。取决于团队的背景; Scrum团队可能会在每次回顾中重新审视它的国防部，或者可能继续使用相同的国防部，除非它学会了新的东西以提高产品的质量。

结论

这些只是Scrum指南中的一些指导原则。我想提出这种区别，因为我经常发现Scrum团队与Scrum规则和指南混淆。几乎没有什么是常见的- 将Sprint计划的时间安排为两个星期的Sprint或开发团队花费太多时间和精力将PBI分解为“任务” - 其他人并不常见。我相信这篇文章将帮助团队确定Scrum的一些方面，他们可以修改这些方面以适应他们的背景。

Scrum参考

• What are the Scrum Events?
• What are Scrum Ceremonies?
• What is Product Backlog Grooming?
• What are the 3 Important Questions in Daily Scrum?
• Scrum Sprint Cycle in 8 Steps
• What is a Sprint in Scrum?
• Heartbeat of Scrum - The Daily Standup
• Daily Scrum Meeting - A Quick Guide
• Why Fixed Length Sprints in Scrum?
• What is Scrum Release Planning?
• What is Sprint Planning?
• What is Sprint Review?