iT邦幫忙

0

什麼是Scrum規則?

要做Scrum,我们所需要的只是16个必需品,即3个角色,3个文物,5个价值观和5个事件。这些16个要素通过Scrum指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助Scrum团队尽可能充分利用Scrum框架来创建最大的业务影响。

Scrum是3355的组合.scrum框架的核心概念可以简单地记为3.3.5.5,如下所示:

3个角色 (scrum roles)

3件文物 (scrum artifacts)

5个事件 (scrum events)

5个值 (Scrum Values)

  • 打开
  • 尊重
  • 勇气
  • 焦点
  • 承诺

3355的目标落后于三个Scrum支柱

  • 透明
  • 检查
  • 适应

“完成”(DoD)的定义是通过Scrum团队的5个事件来实现3个支柱来实现的。

3355 Scrumæ¡  †æž¶

3355 Scrum框架

Scrum规则 (Scrum Rules)

当我提到规则时,我的意思是那些无法修补以适应特定背景的方面。例如:没有3个角色,你不能做Scrum - 产品负责人,开发团队和Scrum Master。

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

例如,Product Backlog Refinement消耗的不超过团队容量的10% (<10% of the sprint duration)。是容量-小时数;故事点数; #天-好吧,没有规则。Scrum团队自我组织并选择最适合他们背景的东西;遵循我们消耗的指导方针,无论如何不超过团队容量的10%

在这篇文章中,我将探讨一些这样的指导方针,这些指南将11个要素绑定在一起,并赋予Scrum团队灵活性以适应这些方面的背景。

1。开发团队规模:开发团队的规模 建议为3-9名成员。根据具体情况,可能会有更多人或更少。它的影响因团队环境而异。

来自Scrum指南:

不到三个开发团队成员减少了交互,导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制,导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多协调。大型开发团队为实证过程提供了太多的复杂性。

2。开发团队的标题/角色: Scrum不承认开发团队中的任何标题/角色。在开发团队中,每个人都是开发团队成员。虽然在组织内,团队成员可能拥有头衔/角色。根据我的经验,我与Scrum有关;我没有遇到任何只有一个职位/角色的团队。

3。每日Scrum的三种问题格式: 我使用过的大多数团队都使用Daily Scrum的3个问题的格式:

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

令人惊讶的是,这3个问题只是开始使用Scrum的团队的模板。只要他们专注于Sprint目标的进展,开发团队就可以以他们认为合适的任何方式构建Daily Scrum。

4。事件的时间框**:事件** 的时间框表示事件为1个月冲刺所允许的最长时间。准则是:对于较短的短跑持续时间,它通常较短。
这是否意味着,对于为期两周的Sprint,Sprint Planning的时间限制为4小时,Sprint Review为2小时,Sprint回顾为1小时和半小时?编号
为尽可能满足他们的目的所需要的事件可以短/长;但不能超过最大分配时间。例如:Sprint规划活动为期2周Sprint可能会在2小时内结束,如果达到目的,或者可能会持续到8小时(如果没有)。

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

6。估算: 该的Scrum指南介绍了积压的产品项目需要估计。他们应该如何估计完全取决于Scrum团队。故事点,理想日,T恤尺码,狗尺码是一些方法。

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

7。工作分解: 在“选择的工作将如何完成?”部分。对于Sprint计划,Scrum指南提到 -

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

这通常有助于发展团队这样做,但这并非强制要求。根据我的经验,我已经看到几个团队没有将工作项目细分到如此精细的水平。他们非常清楚如何将功能转换为“完成”增量。

8。Sprint评审: 这是一项重要的Inspect&Adapt活动,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 Planning的时间框修改为4小时进行为期2周的冲刺,或者开发团队花费太多时间和精力将Product Backlog Items (PBI) 分解为“任务” - 其他人则不那么常见。我相信这篇文章将帮助团队识别Scrum的一些方面,他们可以修改这些方面以适应他们的背景,以及他们能够区分那些无法改变的方面。

Scrum Artifacts


尚未有邦友留言

立即登入留言