注：本文参考了笔者在某 T 和某 T（没写错）的工作经验综合整理而成。受益良多，特别鸣谢~

什么是敏捷开发

敏捷：在动荡的业务环境中获得利益并响应变化的能力。

敏捷思想		传统方法
人和交互	重于	过程和工具
可以工作的软件	重于	求全责备的文档
客户协作	重于	合同谈判
随时应对变化	重于	循规蹈矩

敏捷开发的一个前提假设是：
用户不可能在产品开发之前，设计之初就完整、明确的提出需求。期望用户在开发过程中不变更需求是不现实的。用户在开发前提出的需求，可能并不是它们最终希望得到的。（什么？您问第一稿方案是什么样的？去翻垃圾桶吧！）

	瀑布流开发	敏捷开发
假设前提	需求确定，极少变更	需求不明确，变更频繁
适合的项目	盖房子，修桥，造汽车、火箭	互联网产品开发
优点	1. 进度反馈明显 2. 实施过程中不需要大量沟通 3. 各流程工作明确，沉浸式强，效率高	1. 反馈周期短，迅速响应需求变化 2. 初期对产品设计要求不高 3. 有利于成员对产品的整体理解
缺点	1. 响应变化的成本高，越后期越高 2. 对「设计」阶段要求极高，需要面面俱到，专业性极强 3. 反馈周期长	1. 需要频繁沟通 2. 对需求评估和节奏控制要求高 3. 需求变更影响开发体验

什么是迭代

小步快跑，持续交付

Eric Ries 曾在《精益创业实战》中提出 MVP（minimum viable product）概念，意即「最简可行产品」——用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。

尽管 MVP 的概念听上去是如此的简单，可是实施起来却没有那么容易。
因为在设计产品原型的过程中，很多设计师是这么做的：把他们认为的产品应当具备的功能罗列出来，然后一一排除，排定优先级，决定哪个功能要在最初的版本中出现，而哪个可以靠后一些。但设计师们往往无法真的只把最必要的功能留在初级版本中——因为诱惑太多。设计师们总希望把很cool、很有惊喜的小细节带给用户来博取赞叹，但从全局来看，其实把某些功能刻意强加进产品，是会削弱产品整体流畅性的。Mr Jamie曾在其博客中把这种心理表现称作「艺术家心结」。

按时间维度

迭代前

1. 编写需求

需求模板，例：
作为「xxx」，我希望「xxx」，以便「xxx」

2. 维护 Backlog

评估优先级

• Step1 - 重要性评估

	体验	效率	质量	风险
KP 需求	5	5	5	5
业务量高	3	4	5	5
业务量中	2	3	4	5
业务量低	1	2	3	5

• Step2 - 紧急性评估
• Step3 - ROI 评估

3. IPM 会议

Iteration Planning Meeting，迭代计划会议。

1. 评估工作量
2. 确定本次迭代范围

注：评估工作量可尝试使用「规模」替代「工时」，有如下好处，非强制

	规模	工时
单位	1(s)、2(m)、3(l)、5(xl)、8(xxl)，斐波那契数	人时/人日
评估	经验不同，评估结果也一样	经验不同，评估结果差异大
衡量效率	可以从规模总量变化看出团队效率的变化	工时总量一定，较难体现团队效率变化

4. 创建 Sprint 拆分任务

每条任务要有：负责人、优先级、工作量（或估时）、排期、状态、进度等

迭代中

1. 每日站会

1. 昨天做了什么？
2. 今天要做什么？
3. 遇到哪些困难、阻碍、风险？（重要）
4. 更新任务状态

2. 迭代进度跟踪

例：规划中 => 开发中 => 产品体验 => 测试中 => 已实现
进度（燃尽）图、故事墙、项目报告（邮件）等

3. 测试

模板、工作流、关联需求、报告

4. 发布

1. 需求 check list
2. 回归测试
3. 发布通知

迭代后

1. Well & Less Well List

匿名反馈，选取前五

2. 质量统计

定时报告

按角色维度

PM 项目经理（Scrum Master）

• 组织 IPM 迭代计划会议
  创建/规划迭代、需求预估、拆分任务、分配责任人
• 跟进迭代进度
  迭代燃烧图、甘特图、进度跟踪、故事墙
• 发送报告
  知会迭代进展、转测试等
• 项目定制
  菜单设置、模板、工作流、可选功能等

PDM 产品经理

• 管理需求
  创建需求、划分优先级、维护 Backlog
• 体验功能
  跟进进度、体验功能、流转需求
• 处理用户反馈
  用户反馈转需求、bug

DE 开发人员

• 查看我的工作
  我的工作台、消息通知
• 开发需求
  修改需求状态、提交关联代码
• 解决 bug
  修改 bug 状态

TE 测试人员

• 测试执行
  测试用例编写、测试计划规划及执行
• bug 跟进
  创建 bug、验证 bug、流转 bug
• 分析统计
  bug 统计、统计报告

Scrum 实践参考

价值观

遵循 Scrum 5 大价值观
一些错误的实践很大可能是因为没有理解 Scrum 的价值观导致的，这里着重提出来：
commitment（承诺）, courage（勇气）, focus（聚焦）, openness（开放） and respect（尊重）

核心物料

Product Backlog

Product Backlog 由 Product Owner 主导维护的 Backlog，由多个 story 组成，维护着所有没有进入 Sprint 的 Backlog。

Story

• 优先级：
  P0：代表本双月一定要完成的。（这就意味着，每个双月交替的时候，需要整体把优先级为 P1 的 story，调整为优先级 P0。）
  P1：代表下双月一定要完成的。
  P2：代表未来会做，但是暂时没有排期。
• 状态：
  PRD ready：一般我们认为 Product Backlog 中的需求已经经过合理拆分，产出详细的文档且经过了 Scrum Team 成员（不用全部）的评审才允许进入 Sprint Backlog，而这种状态我们成为需求 Ready。

Sprint Backlog

Sprint Backlog 由开发团队主导维护的 Backlog，在 Sprint Plan Meeting 时由开发团队决定哪些需求（一般是满足需求 Ready）可以从 Product Backlog 中加入到 Sprint Backlog。理论上，每个 Sprint 都会新建一个 Sprint Backlog；每天都会对当前 Sprint Backlog 进行更新，以观察进度，暴露风险
每个 story 都要指定 owner（一般为 RD），然后由 owner 拆解为更细的 task

Task

• 优先级
  与 story 优先级类似，更细粒度的优先级标识。只反映本 Sprint 内 task 的相对优先情况
• 估时
  用于辅助排期。每天按照 6 小时有效工作时间算，一个 task 估时一般不超过 12h，超过意味着可以再拆分
• Due Date
  完成日期，每天对进度时都可能有变化，所以建议增加一个 Plan Date 作为对比。风险和进度主要靠此体现
• 状态
  一般分为：Done、Doing、Todo、Pending、Closed。视项目情况变通
• 进度（可选）
  百分比，比 Due Date 更细粒度的进度体现
  例（asana 进行 sprint 管理）：
  

核心流程

Grooming

每个 Sprint 「中点左右」的一天。PM 和 RD 需要提前整理好 Product Backlog，按优先级高低，逐条 Review Story，在需要时调整优先级。
会议通常 1-2 小时。会议结束后，应大体确认下个 Sprint 需要做的 Story，相对优先级以及对时间的粗估。此时 story 允许处于 PRD 非 ready 状态。

Plan meeting

每个 Sprint 的第一天。RD 需要提前（也可在会上进行）把 Grooming 后 ready 的 story 拆分成 task，并估时，排优先级，排期。在会上进行 task 调整，比如前后端联调，任务依赖，排期有风险等。理论上未 ready 的 story 不应进入到当前 Sprint，具体要视情况而定。
会议通常 30-60 分钟。会议结束后，形成 Sprint Backlog，每日站会使用。
注：排期参考

• 2 个自然周，10 个工作日
• 每天按照 6 小时有效工作时间算
• 每个迭代单人有效时间总计 60 小时

Daily Stand-up meeting

每天早上站会。逐条过 Sprint Backlog 的 task，并修改状态，暴露问题和风险。通常 10-30 分钟。

引用

1. 【深度好文】从瀑布到敏捷——漫画解读软件开发模式变迁史
2. 传统模式VS敏捷开发：回不去的瀑布流，逃不出的迭代