敏捷项目管理入门（Scrum）

（整理自内部培训PPT）

1 敏捷

1.1 敏捷的由来及敏捷宣言

2001 年 2 月，Martin Fowler 等 17 位著名的软件开发专家在美国雪鸟滑雪圣地的一次聚会中，正式提出敏捷(Agile)的概念，并签署了《敏捷宣言》。包含 4 条价值观和 12 条原则。

1.1.1 敏捷软件开发宣言（价值观）

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

注意，这不意味着流程、工具、文档、合同、计划都不需要了，它们有用，只是相对而言，左项更应该重视。

1.1.2 敏捷宣言遵循的 12 条原则

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

1.2 敏捷的本质

汉语词典中对“敏捷”的定义是“反应迅速快捷”。敏捷软件开发，就是要快速响应变化，持续为客户产出有效价值。

《敏捷宣言》签署 13 年后，Dave Thomas 写下 《敏捷已死》，再次探讨了敏捷的本质。部分摘录如下。

1.2.1 如何用敏捷方法来做事

做什么：

• 找到你的位置
• 向你的目标迈出一小步
• 基于你所学来调整你的认知
• 重复以上步骤

怎么做：

当面对两个以上提供大致相同价值的选择时，采取使得未来的变化变得更加容易的路径。

这就是践行敏捷需要做的全部内容，而不是一堆贴上“敏捷”标签的繁琐的过程和工具。

1.2.2 敏捷不是标签

• 你不是一个敏捷程序员——你是一个设计程序很敏捷的程序员。
• 你不是在一个敏捷团队工作——而是你的团队表现得很敏捷。
• 你不使用敏捷工具，而是你运用的工具让你更敏捷。

“敏捷”一词很容易运用于任何东西，但敏捷性是很难挪用的。

这是很重要的——标签可以进行买卖。通过参加一个短期课程,可以突然添加一个敏捷的标签和头衔，但是你不能买经验，你只能通过努力来拥有它。

1.3 为什么用敏捷

在乌卡时代里，现实复杂多变，通往目标的路上充满未知和挑战，我们无法提前做好一切准备，甚至目标本身也在发生变化。

这种情况下，要求我们能够快速响应变化，及时处理前进道路上遇到的任何新问题，随时可以调整航向。

传统的瀑布模式，生产周期太长，对于生产过程中出现的变化来不及响应。等产品上线后，发现并不符合客户的预期，使用价值极低，这是最大的浪费！

2 Scrum 方法

2.1 Scrum 简介

2.1.1 Scrum 由来及其与敏捷的关系

• 1991年，DeGrace 和 Stahl 在《Wicked Problems, Righteous Solutions》一文中将所谓整体方法命名为 Scrum。
• 1995年，在 OOPSLA‘95 会议上，Sutherland 和 Schwaber 共同发表论文介绍 Scrum 方法。
• 2001年2月，由 Martin Fowler，Jim Highsmith 等17位软件开发专家起草的敏捷宣言发表，敏捷联盟成立。

Scrum 是迭代式增量软件开发过程，通常用于敏捷软件开发。先有了 Scrum，后有敏捷的概念。事实上，提出敏捷概念的时候，已经有一些成熟的开发方法存在了，这波人是从现有的优秀开发方法中抽取共性。可以说，“敏捷方法”是一个抽象类，“Scrum 方法”是它的一种实现。

2.1.2 Scrum 敏捷开发模式

• 将原始需求拆分成许多不同的用户故事，每个用户故事可以独立开发、测试、上线，最后汇总到一起。
• 所有用户故事处理完毕后，完成第一次迭代。与需求方沟通，得到新的需求。
• 重复以上步骤，直到产出客户满意的软件。

2.2 用户故事

2.2.1 什么是用户故事

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

2.2.2 INVEST 法则

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循 INVEST 法则。

• 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
• 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
• 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
• 可估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
• 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
• 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

2.3 Scrum敏捷项目管理流程

1. 将整体的产品需求，做一次粗粒度的切分，转换成 Epic 或相对大粒度的用户故事，放在 Product Backlog 里；
2. 从 Product Backlog 里抽出优先级最高的一块需求，切分为粒度较小的用户故事，放入 Sprint Backlog；
3. 从 Sprint Backlog 里抽出优先级最高的一些用户故事，放入 Sprint 迭代；
4. 一个 Sprint 迭代，周期通常为 2-4 周。由于有每日站会，所以每天也是一个小迭代；
5. 一个 Sprint 结束后，会产生一版可交付的产品；
6. 持续以上过程。

2.4 Scrum 团队角色及职责

2.5 Scrum 四大仪式

1. 发布计划
   • 确定发布功能集
   • 确定迭代长度（每个版本的时长）
   • 确定团队成员
2. 迭代计划
   • 迭代目标（即版本的目标）
   • 迭代包含的 Story（具体每条需求）
   • 演示（Showcase）日期
   • 每日站会时间、地点
3. 每日站会
   • 在白板前进行
   • 围绕着卡片说
   • 自己移动卡片和更新状态
   • 控制时间
4. 迭代回顾会议
   • 整个团队参加
   • 相对安全的环境
   • 回顾迭代状况
   • 共同确定改进点
   • 有明确的 Owner

另一个常见仪式：

• 工作成果演示
  • 真正完成工作
  • 团队工作得到认可
  • 吸引干系人注意
  • 收集反馈

3 其他

3.1 Scrum 常用工具

• 燃尽图、燃起图、累积图、多重燃起图
• 团队日历

3.2 敏捷转型

一家公司若想采用敏捷方法进行项目开发，必然有一个过程，不是一蹴而就的。参考：敏捷转型。