敏捷Scrum - 快速演示
快速介绍敏捷，侧重于Scrum。
目录
敏捷宣言
敏捷宣言于 2001 年 2 月由 17 名软件开发者在犹他州雪鸟度假村会议上创建。
“我们正在通过实践和帮助他人实践来探索更好的软件开发方式；通过这项工作，我们认识到以下价值：
- 个体和互动 胜过流程和工具
- 可工作的软件 胜过详尽的文档
- 客户协作 胜过合同谈判
- 响应变化高于遵循计划
也就是说，虽然右侧的项目有其价值，但我们更看重左侧的项目。”
根据上述宣言，重点放在了左侧的项目上。正如我们在接下来的章节中看到的，保持敏捷意味着：
- 拥有一个自组织的团队，团队内部有更好的互动和沟通；
- 开发重点是创建可工作的软件，并在每个迭代中交付业务价值；
- 与客户进行真正的协作，以便在开发过程中提供持续反馈的可能性；
- 灵活应对范围变更，并尽快响应。
敏捷方法论
主要的敏捷方法论有：
- Scrum
- 看板 (Kanban)
- 极限编程 (XP)
- 特性驱动开发 (FDD)
- 敏捷统一过程 (AUP)
通过使用敏捷，项目取得了更大的成功，如下面的统计数据所示。
正如你在上面的统计数据中看到的，与使用瀑布经典方法开发的项目的相比，使用敏捷方法开发的项目的成功率有了很大的提高。
Scrum 概述
在上面的图片中，我试图用一个单一的图表来展示整个 Scrum 方法的概览。你可以在接下来的章节中找到关于 Scrum 角色、工件、仪式（会议）和冲刺（迭代）的详细信息。
冲刺
Scrum 是一种迭代方法论，Scrum 中迭代的名称是“Sprint”。
在下面的图表中，你可以看到一个 Scrum 项目开发被划分为 24 个迭代，持续一年。
Sprint 0 – 是在项目开始时进行的特殊迭代，它形成了后续每个迭代构建的基础。此迭代的持续时间将根据所需功能的复杂性和现有知识而有所不同。在此特殊 Sprint 中，进行足够的架构和系统设计，以便开始开发并启动第一个 Sprint。（在后续迭代中，将根据需要执行额外的架构和系统工程）。
Sprint 0 之后，所有其他 Sprint 长度必须相同。 长度可以为 1 到 4 周。推荐长度为 2 周。
在 Sprint 开始时，团队将对范围有明确的承诺，当前 Sprint 的范围在 Sprint 期间不能更改。
短迭代使产品负责人能够更快地获得客户反馈，开发人员更快地进行估算，并更快地更新计划，从而缩短了整个反馈周期。在发布之前，任何项目都应至少有三次让利益相关者提供反馈的机会。
用户故事
用户故事 (简称 US) - 是一个简短、简单的功能描述，从需要新功能的人的角度来讲述，通常是系统的用户或客户。
验收标准 - 完成 US 所需满足的活动列表
INVEST 有助于记住一套被广泛接受的标准或清单，用于评估用户故事的质量。
- I (独立 - Independent)
- N (可协商 - Negotiable)
- V (有价值 - Valuable)
- E (可估算 - Estimable)
- S (小型 - Small)
- T (可测试 - Testable)
对于用户故事，应使用以下模板：作为一个 <用户类型>，我想要 <某个目标>，以便 <某个原因>。
史诗 (Epic) – 是一个用户故事，涵盖了大量的功能。由于史诗通常对于敏捷团队来说太大，无法在一个迭代中完成，因此在开始工作之前，它会被分解成多个较小的用户故事。
示例：史诗 1 作为一个用户，我可以备份我的整个硬盘，以便在数据丢失后能够恢复数据。
这个史诗可以分解成一组用户故事
US1 作为一个高级用户，我可以根据文件大小、创建日期和修改日期来指定要备份的文件或文件夹，以便…
…
US12 作为一个用户，我可以指定不备份的文件夹，以便我的备份驱动器不会被我不需要保存的东西填满，以便…
扑克牌估算技术用于以用户故事点 (SP) 来估算用户故事，可能的值为（斐波那契数列）：1, 2, 3, 5, 8, 13, 21。通过使用卡片，整个团队对每个用户故事进行估算。用户故事的估算由团队秘密进行，然后同时揭示卡片，估算值较高和较低的团队成员必须解释他们的估算原因。此用户故事的估算过程会重复进行，直到整个团队对该用户故事的估算相同为止。
用户故事点 (Story Points) - 是相对值，估算为 2 个用户故事点的故事，其工作量应是估算为 1 个用户故事点的项目的两倍。用户故事点代表开发一个故事的工作量，这包括所有可能影响工作量的因素，包括工作量的大小、复杂性和风险。
提示：每个用户故事必须
- 使用上述模板创建；
- 遵守 INVEST 原则；
- 有一组验收标准；
- 使用扑克牌估算技术由团队以用户故事点进行估算。
Scrum 角色
产品负责人 (Product Owner) - 是一个人，负责产品待办事项列表（范围），并负责在每个 Sprint 和整个产品开发过程中对产品功能进行优先级排序。
团队 (Team) - 是一个自组织的团队，包括所有参与最终产品设计、开发、测试和交付的人员。敏捷团队的目标是交付满足用户需求的高质量产品。
Scrum Master - 促进 Scrum 流程，并创造一个有利于团队自组织的有利环境；可视为整个团队的教练；帮助解决障碍；保护团队免受外部干扰和分心；执行时间盒。
Scrum 工件
产品待办事项列表 (Product Backlog) – 是一个不断变化、动态排序的需求列表，按业务价值排序。产品负责人将需求分解为用户故事。产品待办事项列表级别的完成定义 (DoD)。
Sprint 待办事项列表 (Sprint Backlog) - 包含当前 Sprint 中已承诺的所有用户故事，并由团队分解为任务。Sprint 待办事项列表中的所有项目都应开发、测试、记录并集成，以满足团队的承诺。
燃尽图 (Burndown Chart) - 显示每个 Sprint 剩余的工作量。它显示了任意时间点剩余的工作量与团队进展之间的相关性。
燃尽图通常由软件工具生成，由 Scrum Master 用于跟踪每个 Sprint，并有助于预测当前 Sprint 的工作何时完成。
Sprint 速度 (Sprint Velocity) - 每个 Sprint 完成的用户故事点数
仪表板
在 Scrum 中，团队使用仪表板来跟踪每个 Sprint 和每个团队成员的用户故事和任务。
在下图（来自 JIRA 工具）中，你可以看到 Scrum 仪表板，用于过滤用户（团队成员）的所有未完成问题。
在上面的仪表板中，你可以看到用户故事及其任务（针对该用户），分为三个类别：
- 待办事项
- 进行中
- 完成
Scrum 仪式
每日 Scrum (Daily Scrum) – 整个团队（包括产品负责人）的每日站会，时长不超过15 分钟。 每个参与者都应回答以下三个问题：
-
昨天我做了什么有助于团队实现 Sprint 目标？
-
我今天将做什么来帮助团队实现 Sprint 目标？
- 我是否看到任何阻碍我或团队实现 Sprint 目标的障碍？
待办事项梳理 (Backlog Grooming) - 待办事项细化会议，以确保待办事项列表中包含相关的、详细的、根据其优先级估算的项目，并符合当前对产品及其目标的理解。会议时长不应超过2 小时。可以每周举行一次待办事项梳理，并且必须在开始下一个 Sprint之前举行一次待办事项梳理！
Sprint 计划会议 (Sprint Planning) - 对于 4 周的 Sprint，会议时间最多为8 小时。新的 Sprint 从这次会议开始。一组来自产品待办事项列表顶部的用户故事被估算成用户故事点，然后分解成任务并以小时为单位进行估算。最后，团队根据团队能力，从新的 Sprint 待办事项列表中选择一组故事（其中可能包含前一个 Sprint 中未完成的用户故事）。
Sprint 评审/演示 (Sprint Review/Demo) - 在每个 Sprint 结束时，会举行一次评审/演示会议。在此会议期间，团队展示他们在 Sprint 期间完成的工作。通常，这会以演示新功能或底层架构的形式进行。对于 4 周的 Sprint，会议时长最多应为4 小时。
Sprint 回顾会议 (Sprint Retrospective) - 帮助团队优化流程的会议。这是一个让每个团队成员反思哪些做得好以及哪些方面需要改进的时间。应明确可行的行动项。对于 4 周的 Sprint，会议时长最多应为3 小时。
优点
使用 Scrum 进行软件开发的主要好处是：
- 提高产品质量
- 增强透明度
- 提高灵活性
- 降低风险
- 最大化生产力
- 改善沟通
- 最大化合作
历史
- 2017 年 8 月 14 日：版本 1.0.0.1 – 草稿版本
- 2017 年 8 月 14 日：版本 1.0.1.1 – 修复图片问题并添加“仪表板”章节
- 2017 年 8 月 15 日：版本 1.1.0.1 – 改进了一些描述，添加了关于用户故事的提示，并添加了“目录”
- 2019 年 10 月 13 日：版本 1.2.0.1 - 更新了关于 Scrum 仪式持续时间的一些详细信息