Scrum 全面指南

Scrum是一种项目管理框架，强调团队合作、责任担当以及朝着明确目标的迭代式进展。它始于一个简单的前提：从你能看到或知道的内容开始。然后，跟踪进展并根据需要进行调整。

Scrum 的三大支柱

Scrum 建立在经验主义之上，认为知识源于经验，决策应基于已知事实。这三大支柱将 Scrum 紧密结合在一起。

为什么选择 Scrum？

Scrum 以增量方式交付功能，而瀑布模型仅在各个阶段交付。传统的瀑布式开发是一种顺序的、阶段性的过程，价值直到项目结束才得以交付。Scrum 通过每轮冲刺（通常每2–4周）交付新功能，而非专注于未来的大型发布，从而改变了这一模式。

Scrum 将复杂的工作分解为可管理的部分，将大型组织划分为小型团队，并将有影响力的项目转化为一系列短期、时间盒化的冲刺.

通过迭代和增量式开发，企业可以更快、更高效地交付客户真正需要的产品和服务。使用 Scrum，你可以在每个冲刺结束时接收并整合客户反馈，这意味着你的成果是基于实际使用情况，而非假设。这使得客户和关键利益相关者更容易积极参与进来。

敏捷 vs Scrum

敏捷是一种实践，能够在整个软件开发生命周期中实现持续迭代的开发与测试。敏捷将产品分解为更小、更易管理的组件。Scrum 只是众多迭代式和增量式敏捷软件开发流程中的一种使我们能够专注于在最短时间内交付业务价值。

Scrum 通常处理那些在项目初期可能发生变化或尚不明确的需求。Scrum 的特点包括：

• 轻量级
• 易于理解
• 难以掌握

Scrum 的优势

以下是 Scrum 为组织、团队、产品和个人带来的优势：

1. 更高质量：有一个实现愿景或目标的框架。Scrum 提供持续的反馈和透明度，以确保质量尽可能高。Scrum 通过以下实践来确保质量：
2. 缩短上市时间：Scrum 已经证明，相比传统方法，能将价值交付给最终用户快30%–40%。
3. 更高的投资回报率（ROI）：更短的上市时间是 Scrum 项目实现更高投资回报率的关键原因。早期收入和效益的积累意味着更高的总回报。这基于净现值（NPV）计算的基本原则。
4. 更高的团队士气：与快乐且投入的个体一起工作是令人满足且富有成效的。自我管理将通常由管理者或组织做出的决策交到敏捷团队 成员。
5. 更强的团队协作：当敏捷团队对项目和产品负责时，他们能够取得卓越成果。敏捷团队通过增强的参与度和沟通来协作，提升质量和项目绩效。

敏捷框架

敏捷很简单。它不是一系列僵化且相互关联的指令。敏捷不是一种方法论。敏捷体现了经验主义的科学方法。它用启发式方法取代了程序化的算法方法，尊重人员和自我组织，以应对不确定性并解决复杂问题。下图展示了敏捷的实际应用，正如肯·施瓦伯和杰夫·萨瑟兰在其著作《敏捷：用一半时间完成两倍工作》中所述，展示了从规划到软件交付的整个过程。

敏捷流程的组成部分

敏捷框架本身很简单。它仅定义了一些通用准则，以及少量规则，角色, 产物，以及事件。然而，这些组成部分中的每一个都对特定目的至关重要，是成功使用该框架所必不可少的。

敏捷框架的主要组成部分是：

• 敏捷角色: 敏捷教练, 产品负责人，以及敏捷团队
• 产物: 冲刺待办事项列表, 产品待办事项列表, 燃尽图，日志等
• 敏捷事件: 冲刺规划，冲刺评审，每日站会，冲刺回顾，等等
• 冲刺

下图展示了Scrum框架的关键要素。该过程已通过Visual Paradigm的敏捷软件工具中的Scrum流程画布进行可视化。

Scrum角色

当一个组织采用Scrum时，首先要理解的是Scrum角色与传统项目管理角色有何不同。尽管Scrum中只有三个主要角色，但它们并不会自动对应到熟悉的职位名称。让我们先简要定义每个角色：

产品负责人

产品负责人是负责代表业务或用户群体的Scrum角色。他们与用户紧密合作，定义产品待办事项列表中的功能。主要职责包括：

• 定义产品的愿景和战略，包括短期和长期目标；
• 提供或收集有关产品或服务的知识；
• 理解并传达客户的需求给开发团队；
• 收集、优先排序并管理产品或服务的需求；
• 对产品或服务的预算负责，包括盈利能力；
• 确定产品或服务的发布日期；
• 每天与开发团队一起回答问题并做出决策；
• 接受或拒绝冲刺中完成的工作；
• 在每个冲刺结束时展示团队的主要交付成果；
• 管理产品待办事项列表。

Scrum主管

Scrum主管是敏捷开发团队的促进者。Scrum允许团队根据敏捷原则自我组织并快速适应。Scrum主管负责管理信息流动。主要职责：

• 担任教练，帮助团队遵循Scrum价值观和实践；
• 帮助消除障碍，并保护团队免受外部干扰；
• 促进团队与利益相关者之间的良好协作；
• 在团队内部倡导常识和透明度；
• 保护团队免受组织内部的干扰。

Scrum团队

Scrum团队（也称为开发团队）由3到9名成员组成，他们必须共同具备交付产品或服务所需的所有技术技能。他们由Scrum主管直接指导，但并非以传统方式管理。他们必须具备自我组织能力、跨职能能力，并对完成所有必要任务负责。

开发团队负责在每个冲刺结束时交付一个潜在可交付的产品增量——涵盖分析、设计、开发、测试和技术写作。Scrum团队的重要特征包括：

• 自我组织：所有团队成员自行管理自己的工作以完成分配的任务。在敏捷Scrum中，没有团队领导或直线经理。每个人都必须投入足够精力来推动自身活动并为团队的成功做出贡献。如果一人失败，所有人皆失败。
• 跨职能：所有团队成员必须具备交付高质量、可交付产品所需的所有知识和技能。可以请专家提供指导，但仅限于将知识传授给团队以弥补技能差距。
• 产品负责人需要具备商业愿景：产品负责人代表客户的声音，必须将客户的需求转化为Scrum主管和开发团队可执行的任务。这通常是一个全职角色。
• Scrum主管并非直线经理：他们帮助指导开发团队，并消除阻碍进展的障碍。

Scrum工件

Scrum工件有助于定义进入团队的工作以及当前正在处理的工作。尽管还有更多工件——如用户故事、发布待办事项列表、燃尽图——但此处我们重点关注核心三项：

产品待办事项列表

产品待办事项列表是一个按优先级排序的用户故事列表，代表产品团队需要或期望的功能。通常由产品负责人维护该列表。

冲刺待办事项列表

冲刺待办事项列表包含在当前冲刺期间需要完成的一组选定项目。关于冲刺待办事项列表与产品待办事项列表之间的关系，有两点需要注意：
1. 团队决定添加哪些内容到冲刺中。因此，团队拥有并负责交付这些项目。
2. 在将项目从产品待办事项列表移至冲刺待办事项列表之前，团队必须确保已掌握所有必要信息。团队通常会制定一份必须满足的条件清单，才能将项目加入。

产品待办事项列表与冲刺待办事项列表
冲刺待办事项列表是Scrum团队承诺在冲刺期间完成的任务列表。在冲刺计划会议中，团队通常选择几个产品待办事项以用户故事的形式，并确定完成每个项目所需的任务，如下所示：

燃尽图

燃尽图是剩余工作随时间变化的图形化表示。剩余工作（或待办事项工作）显示在纵轴上，时间显示在横轴上。它是一个持续更新的待办工作图表。可用于预测所有工作何时完成。它常用于敏捷软件开发方法（如Scrum），但也可适用于任何具有可衡量进度的项目。剩余工作可按时间或故事点.

Scrum事件

沟通是关键！Scrum依赖于所有方面的透明度（Scrum支柱#1）。基于这一核心原则，该框架围绕一系列关键事件构建，以确保另外两个支柱——检查与调整，如下表所示：

事件	检查	调整
冲刺计划	产品待办事项列表 （承诺于回顾) （定义为完成)	冲刺目标 预测 冲刺待办事项列表
每日站会	向冲刺目标的进展	冲刺待办事项列表 每日计划
冲刺评审	产品增量 产品待办事项列表（发布） 市场商业状况	产品待办事项列表
冲刺回顾	团队协作 技术与工程实践 完成的定义	具体改进

注意：在每个冲刺期间，Scrum中有五个关键会议，如下所示：

冲刺规划

每个冲刺都从规划开始。团队必须确定并承诺在冲刺中交付的内容。可能的事项始终从冲刺待办事项列表中提取，如下所示：

这就是Scrum主管可以大放异彩的地方。产品负责人从商业/客户的角度定义所需内容，Scrum团队确定他们认为自己能够交付的内容，而Scrum主管则确保双方的最佳契合。

每日站会

团队一旦承诺在冲刺中交付的内容，就会举行每日站会。核心目标是确保每位团队成员（以及可能的观察者）完全了解工作的状态和进展：

• 我昨天做了什么？
• 我今天要做什么？
• 什么阻碍了我？

每日更新为团队提供了即时反馈。会议时间简短——每人不超过3分钟。

注意：观察者只是来观察的。Scrum主管必须尽量减少外部和内部的干扰。

冲刺评审会议

冲刺评审或演示在冲刺结束时举行，用于检查增量。团队根据完成的定义展示增量，聚焦于冲刺目标。产品负责人审查并接受已交付的增量。

冲刺回顾

冲刺回顾通常是冲刺的最后一项活动。许多团队在冲刺评审后立即进行。整个团队——包括Scrum主管和产品负责人——都应参与。一小时的回顾通常已足够。这次会议让团队能够反思：

1. 我们应该开始做什么？
2. 我们应该停止做什么？
3. 我们应该继续做什么？

目标是持续提升团队效率。

待办事项列表细化

可以把产品待办事项列表看作项目的路线图。随着团队协作，他们会创建并更新完成项目所需的所有事项列表，确保所有必要需求都得到满足。

冲刺

在Scrum框架中，实现Scrum产品待办事项列表中一项内容所需的所有活动都在一个冲刺内完成（也称为“迭代”）。冲刺总是很短——通常为2到4周。每个冲刺都遵循一个明确的流程，如下所示：

如前所述，产品待办事项列表中的项目会优先排序并选入冲刺待办事项列表。一个冲刺只包含少数几个主要项目——对单个项目的工作量估算不足，可能会显著影响冲刺。由于较大的项目往往更难估算和理解，冲刺失败的风险也随之增加。经验丰富的Scrum团队会投入时间和精力，将复杂或大型项目（例如用户功能或史诗）分解为更小的用户故事（或进一步分解为任务或子任务）。

史诗

史诗记录了一大堆工作。它本质上是一个“大型用户故事”，可以分解为许多较小的故事。完成一个史诗可能需要多个冲刺。因此，在开发中使用史诗时，必须将其分解为更小的用户故事。

史诗在项目生命周期的早期引入。它们是高层次的，几乎是面向营销的功能点。

我们称大型故事为“史诗”，以传达其规模。这就像一部电影。如果我告诉你一部电影是“动作冒险片”，你就能大致了解预期内容——可能是汽车追逐、枪战等。同样，将一个故事标记为“史诗”，有时也能传达额外的背景信息。

用户故事

用户故事是对产品需求或商业案例的简要陈述。通常用简单语言撰写，以帮助读者理解软件应如何运作。产品负责人创建故事，然后Scrum团队成员将故事分解为一个或多个Scrum任务。

用户故事通常是最终用户可见的功能。它们遵循以下格式：“我想[做某事]，以便[我可以实现一个目标]。”它们为客户/用户带来价值。这是客户的产品需求。

示例：“作为一名客户，我希望创建一个账户，以便查看去年的购买记录，帮助我规划明年的预算。”

任务

相比之下，任务更具技术性。任务通常涉及代码、设计、创建测试数据、自动化等。这些通常是个人职责。任务不以用户故事的形式编写，更具技术性。

示例：“使用 Material Design 评估用户界面角度”或“将应用程序提交到 App Store。”