在当前的 IT 行业，敏捷的概念已经相当流行。每个人都在谈论。几乎所有的 IT 公司都采用了某种程度的敏捷。
在敏捷开发的范畴内还有很多方法，包括极限编程（XP）、Scrum、水晶方法、自适应软件开发（ASD）、特征驱动开发（FDD）、动态系统开发（DSDM）和轻量级。RUP、测试驱动开发 (TDD) 等。在众多敏捷开发方法中，Scrum 的实现更为流行。
敏捷还是瀑布？见数字
Standish Group 的最新报告涵盖了他们在 2013 年至 2017 年间研究的项目。在此期间，敏捷和瀑布式的成功、挑战和失败的总体突破如下所示，敏捷项目成功的可能性大约高出 2 倍，失败的可能性降低 1/3。
（来源：viabilitychicago.com — 比较瀑布和敏捷项目的成功率）
本文主要分享对 Scrum 的理解、Scrum 的实现过程以及 Scrum 的实现带来的变化，并说明什么是运行中的 Scrum。
什么是 Scrum？
Scrum 是一个用于开发和维护复杂产品的框架，是一个增量、迭代的开发过程。在这个框架中，整个开发过程由几个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 为 2 到 4 周。
在 Scrum 中，使用产品 Backlog 来管理产品的需求。产品积压按照执行的优先级排序，以商业价值为主要排序原则。在 Sprint 中，Scrum 团队从产品 Backlog 中选择最高优先级的需求进行开发。在 Sprint 计划会议上讨论、分析和估计选定的需求，以获得称为 Sprint 待办事项的任务列表。当 Scrum 团队完成 Sprint backlog 列表中的所有任务时，Sprint 结束并进入下一个 Sprint 迭代周期。
为什么 Scrum 在一些公司失败了
Scrum 具有很大的价值。但是，在一些公司中实施 Scrum 很困难。有人说 Scrum 在他们的组织中没有实质性的影响。他们为什么会有这样的结果？主要原因可能是：
- 敏捷更快 ——项目团队对敏捷缺乏正确的理解。它简单地认为敏捷是快速的，即追赶进度，可以不受任何系统的限制。
- 敏捷更快，或者我们需要加班 ——我听说有些公司必须开发一个新功能。由于scrum的实施，项目组需要加班，2周以上的开发任务会在1周内发布。实施 Scrum 意味着项目团队加班加点，导致项目团队的敏捷性产生“恐惧”；
- Product Backlog维护不好——PO 无法胜任工作，无法拆分有效的用户故事，或者用户故事拆分不合理，无法实现增量生成开发；
- 团队组建问题 ——Scrum对自组织团队的要求很高，但很多团队成员觉得自己达不到自组织的标准；
- 缺乏敏捷文化 ——Scrum 提倡工作的透明化、项目的实时完成和每个人的任务识别。冲刺板和项目燃尽图一目了然，很多人不习惯；
- 检查和适应不到位 ——在迭代过程中，不能及时发现问题，或者发现问题，不能有效解决问题，让项目组感到沮丧。还有很多。
如果 Scrum 的知识只停留在：
“早上有个想法，下午实现，晚上上线。”
这是不合适的。在我看来，Scrum 绝对是有价值的。Scrum 的主要功能包括：
- Scrum 可以确保优先开发对客户有价值的产品 backlog，更好地满足用户的需求。
- 与瀑布流程下的开发方式相比，通过实施Scrum，团队可以使开发效率翻倍，最大限度地发挥团队的作用；
- Scrum 可以缩短开发周期，提高项目交付效率。
但是，实施 Scrum 并不意味着它不受规则和项目约束。那么实施 Scrum 的正确姿势是什么？
实施 Scrum 的步骤
1. 分配采购订单
PO是Product owner，是一个角色，PO是管理产品to-do list的唯一所有者。当然，在一些公司中，PO已经作为一个组织存在——比如我们公司在Scrum的实施中已经将PO作为一个组织实现了。
作为业主，一定要有大局；深入了解行业信息和方向；能够把握产品的方向，负责产品的短期和中长期规划和管理；能够根据公司战略要求进行用户调研和产品功能规划，跟踪不断变化的需求，不断创新产品。
此外，如果您将 PO 用作组织，在软件开发项目中，PO 团队可能包括其他利益相关者，例如产品经理、最终用户等成员。
2.组建开发团队
团队是产品的实施者，负责在每个 Sprint 结束时交付潜在的可交付增量和“已完成”的产品增量。
团队主要包括开发和测试人员，团队必须能够实现PO对产品的愿景。
团队的规模应该在 5 到 9 人左右。
Scrum 团队也应该是跨职能的，具有“全栈”能力的成员更可取，即使 在大多数公司可能难以实施。
3. 选择 Scrum Master
Scrum Master 负责 Scrum 流程并为 PO 和开发团队服务。Scrum Master要有仪式感，能有效高效地组织迭代计划会议、日常常设会议、功能演示会议、回顾会议；Scrum Master 必须具有高度的执行力并保持可信度以帮助团队。专注于交付目标和质量目标，确保团队高效交付高质量产品；推动团队建立高效的流程，指导团队敏捷价值观、原则和敏捷实践；负责培训团队其他成员，确保正确使用 Scrum；沟通、问题管理、冲突解决，帮助团队消除一切障碍。
4.维护产品Backlog
Product Backlog 是所有 backlog 项目的集合，基于公司的战略和产品愿景。PO将产品积压中的所有项目按照业务价值按照优先级排序，形成优先项目列表。产品积压可以作为产品开发的“路线图”。 要了解产品上下文，产品待办事项是最好的参考。
我们每天都面临来自新竞争对手的新需求，这意味着 PO 必须不断优化其产品设计并调整产品积压的优先级以应对新的变化。
在此过程中，PO 应咨询所有利益相关者和团队，以确保产品积压反映用户的真实主张。
5. 使用故事点的敏捷估计
相对敏捷的估计通常在 sprint 计划中执行或在 sprint 期间进行修改，并且产品积压由团队与负责实际开发和测试工作的人员一起评估。
为了在实践中更高效地进行 sprint 计划，PO 和 Scrum Master 会在 sprint 计划会议之前进行粗略的估算。他们需要问这些问题，例如：
- 看看sprint计划是否可行？
- 是否有足够的信息来完成这些事情？
- 产品积压项目拆分是否合理？
开发团队进行估算时，建议摒弃传统方法（即分配多少小时任务），采用敏捷估算方法，利用故事点——斐波那契数（1、2、3、5） , 8, 13, 21…) 用于评估实施项目所需努力的表格。
在估算时，团队需要首先确定一个可能是用户故事形式的待办事项，作为估算的参考。另外需要注意的是， 当评估的单故事点大于21时，需要再次拆分用户故事，单用户故事点不超过8是理想状态。
6. Sprint 计划会议
这是第一次真正的 Scrum 会议。团队、Scrum Master 和 PO 坐在一起计划 sprint 的内容。 作为一个软件开发项目，进入规划冲刺的用户故事，应该已经拆分了用户故事，完成了视觉设计。
sprint 周期一般是固定的，多为 2 到 4 周。团队从产品待办事项列表中优先级最高的用户故事开始，看看在一个 sprint 中可以完成多少工作。
如果团队已经进行了多次冲刺，请参考：
- 在之前的迭代中完成的“故事点”，
- 团队可能会估计此迭代的大致故事点。
- “故事点”相当于团队的速度。
Scrum Master 和团队应该努力在每个 sprint 迭代中增加这个数字。
所有团队成员都应该就 sprint 的目标形成共识，即在 sprint 迭代中需要完成什么。在 sprint 计划会议上，PO 需要告诉团队用户故事实施的优先顺序。团队承诺他们将能够在下一个 sprint 迭代中完成多少个故事。在冲刺过程中，任何人都不能擅自单方面更改冲刺内容。
7. 每日站立会议
每日站会是 Scrum 活力的源泉。参与者一般包括 PO、Scrum Master 和团队。团队每天在固定地点和固定时间进行内部沟通。时间一般 是早上，时间不超过15分钟，站着。Scrum Master 向团队 成员提出以下问题：
- 你昨天做了什么？
- 你今天打算做什么工作？
- 什么是障碍和障碍？
这样做的意义在于让整个团队清楚地知道在这个 sprint 周期内每个任务的进度，以及所有的任务是否能够按时完成。
团队的任务不是自上而下分配的，而是由他们主动和自愿决定的。如果上一个任务没有完成，就不能申请下一个任务，也不能申领两个不能在同一天完成的任务。
Scrum Master 负责消除团队成员面临的障碍。
8. 使用 Scrum 任务板跟踪项目进度
在 Scrum 中，工作必须是透明的，最常见的做法是实现一个 Scrum 任务板。
有些团队擅长使用第三方工具来使用电子 Scrum 板，例如 Visual Paradigm 或 Jira；一些团队乐于使用大型离线物理白板。
无论您使用电子 Scrum 板还是物理白板，看板的列通常包括三个部分：待办事项列表、正在进行的项目和已完成的项目。随着迭代进度的推进，团队每天都会及时将此事更新到对应的Scrum看板栏目。
9. 使用燃尽图跟踪进度
另一个使工作透明的工具是倦怠图。在下图中，一个轴代表工作量，另一个代表时间。Scrum Master 每天都会记录下要完成的剩余点数，然后将它们绘制在倦怠图上。理想情况下，该图是一条向下的曲线，随着其余工作的完成而烧毁为零。
10. 产品展示
Scrum 指南的演示部分称为 Sprint 评审会议，它指出它应该包括演示开发团队完成的工作并回答有关产品增量的问题。会议通常在本次迭代发布之前举行。 本次会议最重要的工作是验证用户故事的实施场景，并接受对每个已完成项目的评估，以实现完成的定义。
这个会议是任何人都可以参加的地方，不仅是 PO、Scrum Master 和团队，还有利益相关者、业务和经理，甚至是客户。
这是一个公开会议，任何人都可以成为参与者，不仅是 PO、Scrum Master 和团队，还包括利益相关者、业务和经理，甚至是客户。
团队应该只展示那些满足完成定义的项目，即无需做更多工作就可以交付的结果。这个结果可能不是一个完整的产品，但至少它对最终用户来说是一个完整且可用的功能。
11. Sprint 回顾展
sprint 回顾会议通常在本次 Sprint 结束后的第二天举行。
冲刺回顾会议应仔细审查以下问题：
- 发生了哪些改进；
- 为什么会这样？
- 为什么当时我们忽略了它；
- 我们怎样才能加快工作。
作为一个团队，为了使这个 sprint 回顾过程有效，团队需要相互信任。我们必须记住基于项目和技术问题的讨论和争论：
- 没有绝对的对、错和担心，
- 鼓励技术碰撞；
- 不能涉及人身攻击的讨论；
- 抵制戴有色眼镜看人，
- 引导大家理性讨论；
- 勇敢地接受别人的挑战，
- 接受自己的不完美。
- 对自己的过程和结果负责，
- 集思广益并寻求问题的解决方案。这是至关重要的。
最后，团队确定了最有价值的改进之一，并将其设置为下一个 sprint 的首要任务。您需要以具体且可操作的方式定义什么是“成功的”，以便您可以快速确定在下一次 sprint 审查会议上是否已做出改进。
最后一个sprint结束后，开始进入新的sprint迭代。
概括
Scrum 是3355的组合，scrum框架的核心概念可以简单的记为3.3.5.5如下：
3个角色
3 神器
- 产品积压
- Sprint Backlog ——Sprint 待办事项列表
- 产品增量——潜在的可交付产品增量
5 个事件
5 个值
- 打开
- 尊重
- 勇气
- 重点
- 承诺
3355 的目标落后于三个 Scrum 支柱
- 透明的
- 检查
- 适应
“完成”（DoD）的定义是通过 Scrum 团队的 5 个事件实现 3 个支柱来实现的。
简体中文
English
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский