Scrum - 指导原则

时间 2019-12-05

标签 scrum 指导原则繁體版

原文原文链接

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

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

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

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

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

＃1。开发团队规模

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

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

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

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

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

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

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

＃4。活动时间表

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

这是否意味着，对于为期两周的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的一些方面，他们能够修改这些方面以适应他们的背景。