共计 3572 个字符，预计需要花费 9 分钟才能阅读完成。
Scrum 框架
Scrum 是一种管理项目的敏捷方式，通常是软件开发。使用 Scrum 进行敏捷软件开发通常被视为一种方法论; 但不是将 Scrum 视为方法论，而是将其视为管理流程的框架。
要做 Scrum，我们所需要的只是 16 个必需品，即 3 个角色，3 个文物，5 个价值观和 5 个事件。这些 16 个要素通过 Scrum 指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助 Scrum 团队尽可能充分利用 Scrum 框架来创建最大的业务影响。
Scrum 是 3355 的组合.scrum 框架的核心概念可以简单地记为 3.3.5.5，如下所示：
3 个角色
产品拥有者
开发团队
Scrum Master
3 件文物
产品积压
Sprint Backlog – Sprint 待办事项列表
产品增量 - 潜在的可发货产品增量
5 个事件
短跑
Sprint 计划会议
每日 Scrum 会议
Sprint 评审会议
Sprint 回顾会议
5 个值
打开
尊重
勇气
焦点
承诺
3355 的目标落后于三个 Scrum 支柱
透明
检查
适应
“完成”（DoD）的定义是通过 Scrum 团队的 5 个事件来实现 3 个支柱来实现的。
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 的一些方面，他们可以修改这些方面以适应他们的背景，以及他们能够区分那些无法改变的方面。
Scrum Artifacts
What are Scrum Artifacts?
Definition of Done vs Acceptance Criteria
What is Definition of Ready in Scrum?
How to Write a Sprint Goal?
What is Product Backlog in Scrum? Who Responsible for It?
How to Refine Product Backlog?
What is Sprint Backlog in Scrum?
