Scrum框架

Scrum是一种管理项目的敏捷方式，通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论，而是将其视为管理流程的框架。

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

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

3个角色

3件文物

产品积压
Sprint Backlog - Sprint待办事项列表
产品增量- 潜在的可发货产品增量

5个事件

5个值

打开
尊重
勇气
焦点
承诺

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

透明
检查
适应

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

Scrum框架和規則

3355 Scrum框架

Scrum依赖于一个自组织，跨职能的团队。Scrum团队是自我组织的，因为没有整体团队负责人决定哪个人将完成哪项任务或如何解决问题。这些是由整个团队决定的问题。

在Scrum中，团队是跨职能的，这意味着每个人都需要从构思到实现。

在敏捷开发中，Scrum团队由两个特定角色提供支持。第一个是ScrumMaster，可以被认为是团队的教练，帮助团队成员使用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的一些方面，他们可以修改这些方面以适应他们的背景，以及他们能够区分那些无法改变的方面。