敏捷开发-Scrum
01 什么是敏捷？
02 敏捷核心
03 敏捷全流程实施
04 总结
目录 CONTENTS
0
1
什么是敏捷？
02 敏捷核心
03 敏捷全流程实施
04 总结
目录 CONTENTS
需求的故事
1.你的“上帝”是怎么期望的 2.项目经理是如何理解的 3.设计师么是怎么设计的 4.程序员们是如何开发的
5.测试员们得到的 6.你的商业顾问是怎么形容的 7.它是怎么付诸于实际的 8.客户到底需要的是什么
敏捷开发更符合软件开发规律
� 软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长
� 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品
传统开发
敏捷开发
传统开发模式
需求分析
功能设计
编程开发
软件测试
什么是敏捷？
� 敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法。
� 敏捷方法
� Extreme Programming (简称XP) 、Scrum 、Crystal Methodologies 、Feature Driven
Development( 简称FDD) 、Dynamic Systems Development Methodology( 简称DSDM) 、
Adaptive Software Development( 简称ASD) 、Pragmatic Programming 等
� Scrum
� Scrum 是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum 包括了一系列实践和预定
义角色的过程骨架。Scrum 中的主要角色包括同项目经理类似的Scrum 主管角色负责维护过程
和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
好的产品不是一蹴而就的——微信发展史
� 2011 年1月21 日微信测试版，支持通过QQ 号导入联系人资料，仅有即时通讯，分享照片
和更换头像功能。－版中，增加了对手机通讯录的读取。
� 2011 年5月10 日，微信增加了语言功能。
� 2011 年8月，微信添加了“查看附近的人”
� 2011 年10 月1日，微信添加了“摇一摇”和”漂流瓶”功能。
� 2012 年4月19 日，增加相册功能，可分享到朋友圈。
� 2012 年7月19 日，增加视频聊天和网页版。
� 2013 年2月5日，支持实时对接和多人语音，扫码，聊天记录迁移等功能。
01 什么是敏捷？
0
2
敏捷核心
03 敏捷全流程实施
04 总结
目录 CONTENTS
Scrum 流程
提倡：早交付，频交
付
敏捷思维
� 价值驱动
胸怀大志，小处做起
精准思想，快速验证
有做不为，懂得取舍
转变思维，三角倒置
尽早交付，及时反馈
价值驱动，优先排序
� 适应变化
� 自组织团队
敏捷宣言
� 个体和交互 胜过 流程和工具
面对面的沟通交流永远好过各自面对冷冰冰的流程工具
有问题随时沟通
� 可工作的软件 胜过 面面俱到的文档
只盯着产品要“大而全且实时更新的文档”是不可取的
但流传到本土以后，很多敏捷团队曲解了这条价值观，完全裸奔不产生任何文档，这样的做法也是非常不恰当的，过少的文档不代表没
有文档。例如用户手册，就是公认的必备文档。
� 客户合作 胜过 合同谈判
签订合同-> 大致需求-> 不断沟通明确需求，修改甚至推翻最初的设想-> 不断迭代，通过沟通要求客户接受新的时间
� 响应变化 胜过 遵循计划
关注市场变化，关注需求变化。不能照本宣科按部就班。外部和内部的变化都需要仔细评估，如果一直遵循原计划，最终只会把产品推
向“死亡”。
� 注：胜过不代表不需要，只是二者同时需要时，前者重要些。
3大支柱 & 5个核心价值观
3大支柱
•透明： Transparency
•检查： Inspection
•适应： Adaptation
5个核心价值观
•承诺
•专注
•开放
•尊重
•勇气
&&
Page 14
统一认识：敏捷= 理念+ 优秀实践+ 具体应用
理念（敏捷核心思想）
敏捷包括3个层次 优秀实践（敏捷的经验积累）
具体应用（能够结合自身灵活应用才是真正敏捷）
理念
优秀实践
具体应用
Page 15
敏捷理念
� 不断调整以适应(Adapting)变化
� 激发团队(Team) 潜能，加强协作
� 聚焦客户价值(Value)，消除浪费
3个角色
产品负责人：
Product Owner
（PO ）
1. 确定产品的功能
2. 决定发布的日期和内容
3. 排序功能的优先级
4. 接受或拒绝开发团队的工作成果
5. 维护PBIs
6. 客户代言人
3个角色
团队负责人：
Scrum Master （
SM ）
1. 组织会议
2. 指导团队成员（敏捷相关，不是技术）
3. 保护、鼓励、帮助，促进团队很多的完成工作
3个角色
团队成员：
Scrum Team
1. 决定要做什么、如何做
2. 在确保目标的前提下，制定行为准则
3. 自组织且充分沟通
4. 分解工作任务
5. 评估工作量
6. 定义DoD （针对所有任务的）
3个工件
� 产品功能列表： Product Backlog （PBIs）
� 冲刺列表： Sprint Backlog（SBIs）
� 燃尽图： Burn-Down Chart
4个会议
� 迭代计划会议： Sprint Planning Meeting
� 每日站会： Daily Meeting
� 迭代评审会议： Sprint Review Meeting
� 迭代回顾会议： Sprint Retrospective Meeting
01 什么是敏捷？
02 敏捷核心
0
3
敏捷全流程实施
04 总结
目录 CONTENTS
团队工作协议
� 又团队成员自己讨论定制出一套所有人都认同的规则（针对日常活动）：
� 制定出来的协议需要每个人都能遵守和互相监督
� 制定的协议要是可实行的
� 有具体判断标准的
� 每个人都认同的
Page 23
产品Backlog 关键要点
� 清楚表述列表中每个需求任务对用户
带来的价值，做为优先级排序的重要
参考；
� 动态的需求管理而非“冻结”方式，PO
持续地管理和及时刷新需求清单，在
每轮迭代前，都要重新筛选出高优先
级需求进入本轮迭代；
� 迭代的需求分析过程，而非一次性分
析清楚所有需求（只对近期迭代要做
的需求进行详细分析，其它需求停留
在粗粒度）。
敏捷工作件：产品Backlog
什么是产品Backlog
� 经过优先级排序的动态刷新的产品需求清单，用来
制定发布计划和迭代计划。
产品Backlog 的好处
� 通过需求的动态管理应对变化，避免浪费；
� 易于优先交付对用户价值高的需求。
产品Backlog 是需求动态管理的载体
Page 24
敏捷管理实践：迭代计划会议
什么是迭代计划会议
� 每轮迭代启动前，团队共同讨论本轮迭代详细
开发计划的过程，输入是产品Backlog ，输出是
团队迭代Backlog ；
� 多团队迭代计划会议要分层召开
� 版本迭代计划会议：将产品Backlog （需
求）分配给团队；
� 团队迭代计划会议：将选取的产品
Backlog 需求转换成迭代Backlog （任务
） ，分配给团队成员；
� 迭代计划会议内容：
� 澄清需求、对“完成标准”达成一致
� 工作量估计、根据团队能力确定本轮迭代
交付内容；
� 细化、分配迭代任务和初始工作计划。
迭代计划会议的好处
� 通过充分讨论，使团队成员对任务和完成标准
理解一致；
� 团队共同参与，促进团队成员更认真对待自己
的承偌。
迭代计划会议的关键要点
� 充分参与：Scrum Master 确保PO 和Team 充
分参与讨论，达成理解一致；
� 相互承诺：Team 承诺完成迭代Backlog 中的
需求并达到”完成标准“，PO 承诺在短迭代周
期不增加需求（2-4 周）；
� 确定内部任务：Team 和PO 协商把一些内部
任务放入迭代中（例如重构、持续集成环境
搭建等），由PO 考虑并与其他外部需求一起
排序 。
迭代计划会议由团队共同确定迭代交付内容和完成标准
用户故事
正面内容：[任务内容]
•No.
•作为：[什么角色]
•我希望：[什么功能]
•1. 。。。
•2. 。。。
•3. 。。。
•估算：_____ story point
背面内容：[验收标准]
•完成了。。。。
•完成了。。。。
•完成了。。。。
•完成了。。。。
Page 26
敏捷工程实践：用户故事（user story）
什么是用户故事
� 用户故事是站在用户角度描述需求的一种方式；
� 每个用户故事须有对应的验收测试用例；
� 用户故事是分层分级的，在使用过程中逐步分解
细化；
� 典型的描述句式为：作为一个XXX 客户角色，我
需要XXX 功能，带来XXX 好处。
用户故事的好处
� 用户故事站在用户视角便于和客户交流，
准确描述客户需求；
� 用户故事可独立交付单元、规模小，适于
迭代开发，以获得用户快速反馈；
� 用户故事强调编写验收测试用例作为验收
标准，能促使需求分析人员准确把握需求
，牵引开发人员避免过度设计。
用户故事的关键要点
� I – Independent，可独立交付给客户
� N – Negotiable，便于与客户交流
� V - Valuable ，对客户有价值
� E - Estimable ，能估计出工作量
� S - Small ，分解到最底层的用户故事粒度
尽量小，至少在一个迭代中能完成
� T - Testable，可测试
初始需求：1.作为网络规划人员，我想要配置一个媒体网关，因
为想要增加网络容量和服务
初次分解：作为网络规划人员，我想把媒体网关参数上传到管理
系统
作为网络规划人员，我想从管理系统下载媒体网关
参数
再次分解：作为网络规划人员，我想用文件方式从管理系统下
载媒体网关参数
用例：用户在管理系统上选择以文件方式下载媒体网关参
数，执行成功后，检查文件是否正确下载到本地且内容正
确
作为网络规划人员，我想用MML 结构方式从管理系
统下载媒体网关的参数
用例:…………
故事样例
用户故事便于团队站在用户角度分解细化需求并制定验收标准
Page 27
敏捷工作件：完成标准（Definition of
Done ）
什么是完成标准
� 基于“随时可向用户发布”的目标制定衡量团队工
作是否已完成的标准，由团队和PO 形成共识；
完成标准的好处
� 共同协商的完成标准是团队的自我承诺，团
队会更认真；
� 用于准确评估团队工作进展；
� 清晰和明确的完成标准保证了每次迭代是高
质量的。
完成标准的关键要点
� 团队自协商：团队根据项目实际情况来定
义完成标准，并严格遵守；
� 有层次：一般分为三个层次：Story级别，
迭代级和发布级，每个级别都有各自的完
成标准。
Story完
成标准样
例
迭代完成
标准样例
发布完成
标准样例
代码合入主干
代码符合规范
代码100% 检视
通过验收测试
通过迭代验收
系统测试用例100% 通过
通过性能测试
所有Story完成
通过回归测试
所有缺陷解决
更新配套资料
完成标准的样例
代码100% 通过单元测试
持续集成无错误
完成标准确保团队每一步前进都奠定在坚实的质量基础之上
建立PBIs
� 用户故事内容
� 优先级（非负整数）
序号 PBIs 估算 优先级
1 作为学生，我希望能登录实训邦，以便于做自己选择的项目 1 15
2 作为学生，我希望能选择参与某个项目，以便于根据自己的爱好选择学习 2 12
3 作为学生我希望能修改个人信息，以便于企业能更好的了解我 2 5
4 ……
5 ……
6 ……
7 ……
8 ……
建立用户故事地图
� 用户故事拆分
� 定义分布版本内容(SBIs)
Sprint - Planning Meeting
� 参与人员：PO 、SM 、Scrum Team
� 第一部分：
估算
拆分任务
决定当前Sprint内容
� 第二部分：
功能设计
形成看板
Page 31
什么是迭代Backlog
� 迭代Backlog 是团队在一轮迭代中的“任务”（Task
）清单，是团队的详细迭代开发计划；
� 当团队接收从产品Backlog 挑选出要在本轮迭代实
现的需求时，召开团队迭代计划会议，将需求转化
为具体的“任务”；
� 每项任务信息包括当前剩余工作量和责任人。
敏捷工作件：迭代Backlog
迭代Backlog 的好处
� 将需求分解成更细小的任务，利于对迭代内进度
进行精确控制；
� 剩余工作量可用来实时跟踪团队当前进展。
迭代Backlog 关键要点
� “任务”由团队成员自己分解和定义，而
不是上级指派，支撑需求完成的所有工
作都可以列为任务；
� 任务要落实到具体的责任人；
� 任务粒度要小，工作量大于两天的任务
要进一步分解；
� 用小时做为任务剩余工作量的估计单位
，并每日重估计和刷新。
迭代Backlog 提供精细的迭代开发计划
任务 责任人 状态
剩余工时
日期
Page 32
敏捷管理实践：每日站立会议
什么是每日站立会议
� 每日工作前，团队成员的例行沟通机制，由
Scrum Master 组织，Team 成员全体站立参加
� 聚焦在下面的三个主题：
� 我昨天为本项目做了什么？
� 我计划今天为本项目做什么？
� 我需要什么帮助以更高效的工作？
每日站立会议的关键要点
� 准时开始：按计划会议制定的时间地点开
会，形成团队成员的自然习惯；
� 高效会议：会议限时15 分钟，每个人都保
持站立，依次发言，不讨论与会议三个主
题无关的事情（如技术解决方案等）；
� 问题跟踪：Scrum Master 应该记录下所有
的问题并跟踪解决；
每日站立会议的好处
� 增加团队凝聚力，产生积极的工作氛围
� 及时暴露风险和问题；
� 促进团队内成员的沟通和协调。
每日站立会议促进团队沟通协调，及时暴露问题
Page 33
敏捷管理实践：可视化管理
可视化管理的好处
� 简单，一目了然 ，降低管理成本；
� 实时状态显示，及时暴露问题；
� 信息同源使团队理解一致，提升团队凝聚力；
� 激励先进，鞭策后进，增强团队进取心。
什么是可视化管理
� 将项目状态 (进度、质量等)通过物理实体（如
白板，大屏幕）实时展示，让团队所有成员直
观地获取当前项目进展信息。
可视化管理的关键要点
� 物理实体：可视化一定要做到物理上的实体化
，大家在公开场所都容易看到，触摸到，（存
在电脑中的文件不是可视化的）；
� 内容精简，易懂：信息展示一目了然，切实对
团队有帮助，切忌贪多求全，难以分辨；
� 实时刷新：延迟的信息拖延问题暴露，降低运
作效率。
可视化管理及时暴露问题，激励团队
Story墙（展示Story进度） 缺陷走势图（展示缺陷解决进展
）
Anatomy 视图（展示系统集成进
展）
Planning Meeting （1）
� 估算
� 1. 相对估算
� 2. 单位：故事点（0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100）
� 3. 游戏：敏捷估算扑克
� 4.决定当前Sprint内容
由PO 组织，按优先级顺序询问团队是否能完成，能完成就下一个，不能完成就停止
2
3
3
1
5
？
Planning Meeting （2）
� 功能设计
1. 架构
2. 接口
3. 数据表
4. 流程图、界面简图
� 形成看板
1. 按顺序贴到看板的To Do 中
Sprint - Daily Meeting
� 参与人员：SM 、Scrum Team
� 时间不超过15 分钟
完成了什么
计划完成什么
进度变慢的原因 or 问题
� 边陈述自己做的事和问题，边移动看板
� 会议结束后更新燃尽图
100
81
70
75 73
50
20
15
5
0
燃尽
图
Day1 Day2 Day3 Day4 Day5 Day6 Day7 Day8 Day9 Day10
0
20
40
60
80
100
120
Sprint Review Meeting(如何完成发布，可以交付)
� 参与人员：PO （或客户）、SM 、Scrum
� 1. 演示本Sprint完成功能
� 2. PO接收或拒绝
Page 38
敏捷管理实践：迭代验收
什么是迭代验收
� 每次迭代开发结束时举行，通过演示可工作的软
件检查需求是否满足客户要求；
� 由Scrum Master 组织， PO 和用户代表（外部
或内部利益相关人）负责验收、Team 负责演示
可工作软件。
迭代验收的好处
� 通过演示可工作的软件来确认项目的进度，具有
真实性；
� 能尽早的获得用户对产品的反馈，使产品更加贴
近客户需求。
迭代验收的关键要点
� 展示“真实”的产品：Team 应在真实环境中
展示可运行的软件，判断是否达到“完成”标
准；
� 收集反馈：PO 根据验收情况及客户反馈意
见，及时调整产品Backlog 。
迭代验收尽早演示可工作的软件，收集反馈意见
Sprint Retrospective Meeting
� 参与人员：SM 、Scrum Team
� 1. 每人反思，总结好与不够好
� 2. 识别高优先级
� 3. 对高优先级的前几项目（建议不超3）讨论出每个人都认同的改进方案
� 4. 在后面的Sprint中改进
� 5. 总结
Page 40
敏捷管理实践：迭代回顾会议
迭代回顾会议的好处
� 激励团队成员；
� 帮助团队挖掘优秀经验并继承；
� 避免团队犯重复的错误；
� 营造团队自主改进的氛围。
什么是迭代回顾会议
� 在每轮迭代结束后举行的会议，目的是分享好
的经验和发现改进点，促进团队不断进步；
� 围绕如下三个问题：
� 本次迭代有哪些做得好
� 本次迭代我们在哪些方面还能做得更好
� 我们在下次迭代准备在哪些方面改进？
迭代回顾会议的关键要点
� 会议气氛：Team 全员参加，气氛宽松自由，畅所欲
言，头脑风暴发现问题，共同分析根因；
� 关注重点：Team 共同讨论优先级，将精力放在最需
要的地方（关注几个改进就够了）；
� 会议结论要跟踪闭环：可以放入迭代backlog 中。
迭代回顾会议是促进团队持续改进的最有效手段
好的 能做得更好的 将来改进的
01 什么是敏捷？
02 敏捷核心
03 敏捷全流程实施
0
4
总结
目录 CONTENTS
总结
� 熟悉流程
� 熟悉Scrum 的334
� 3个角色：PO, SM, Scrum Team
� 3个工件：PBIs, SBIs, Burn-Down Chart
� 4个会议：Sprint Planning Meeting, Daily Meeting, Sprint Review Meeting, Sprint
Retrospective Meeting
项目流程
Review
Meeting
Retrospectiv
e Meeting
Sprint
Planning
Meeting
Daily
Meeting
Kanban &
Burn Down
Chart
.
20
-
22
Start Scrum
Training
Start to Sprint
…………
Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6
…
…
Release1/Milestone1 Release1/Milestone2
周报
Sprint
报告
附录——其他信息
� 对敏捷的常见误解
� 优秀实践: 业界敏捷优秀实践概览
� 敏捷团队实践：完整团队
� 敏捷工程实践：结对编程
对敏捷的常见误解
误解一： 敏捷开发意味着可以不需要文档、设计和计划
误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合
误解三： 敏捷只适用于小项目开发
误解四： 敏捷只会对研发产生改变
误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了
误解六： 引入敏捷只需要按照既定的步骤去做就可以了
误解七： 敏捷是CMM 的替代品，是另一种流程
误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了
Page 46
优秀实践: 业界敏捷优秀实践概览
结对编程
测试驱动开发客户参与验收
计划游戏
代码集体所有
每日站立会议
产品backlog
（带优先级的需求清单）
燃烧图
迭代计划会议
回顾会议
Scrum Master
Product Owner
Anatomy （系统解
剖）
One Track
Systemakut （缺陷管理和决策
）
重构
完整团队
稳定开发节奏
Lagomising （需求决策
）
隐喻
电信业偏重大规模产品实践、Scrum 偏重项目管理，XP 偏重编程实践
电信业
Scrum XP
持续集成
迭代交付
Page 47
什么是完整团队
� 敏捷开发中，以Story为单位的持续交付要求系
统组、开发和测试等跨功能团队进行密切协同
，相互独立的功能团队难以应对。
� 完整团队是跨功能领域（需求分析师、设计
师、开发人员、测试人员、资料人员等）的人
员组成一个团队，坐在一起工作，团队成员遵
循同一份计划，服从于同一个项目经理。
完整团队的好处
� 有助于团队成员形成共同目标和全局意识，促
进各功能领域的拉通和融合；
� 通过面对面沟通提升沟通效率。
� 实现团队成员的高度协同，支撑高密度地、持
续地、短周期的交付。
完整团队的关键要点
� 成员来自多功能领域：团队拥有完成目标
所需的各职能成员；
� 坐在一起办公：团队成员无障碍地沟通；
� 团队保持相对稳定：临时组建的团队生产
效率较低，团队稳定非常关键。
完整团队聚焦客户需求交付，提高协作效率
敏捷团队实践：完整团队
敏捷工程实践：结对编程
Page 48
什么是结对编程
� 两位程序员在一台电脑前工作，一个负责敲入代
码，而另外一个实时检视每一行敲入的代码；
� 操作键盘和鼠标的程序员被称为“驾驶员”，负责
实时评审和协助的程序员被称为“领航员”；
� 领航员检视的同时还必须负责考虑下一步的工作
方向 ，比如可能出现的问题以及改进等。
结对编程的好处
� 有助于提升代码设计质量；
� 研究表明结对生产率比两个单人总和低 15% ，
但缺陷数少 15% ，考虑修改缺陷工作量和时间
都比初始编程大几倍，所以结对编程总体效率
更高（source: The Economist ）；
� 结对编程能够大幅促进团队能力提升和知识
传播。
结对编程的关键要点
� 程序员应经常性地在“驾驶员”和“领航员”间切换
，保持成员间平等协商和相互理解，避免出现
一个角色支配另一个角色的现象；
� 开始一个新Story开发的时候即可变换搭档，以
增进知识传播；
� 培养团队成员积极、主动、开放、协作的心态
能够增进结对编程效果；
� 实施初期需要精心辅导，帮助团队成员克服个
性冲突和习惯差异。
结对编程提高代码质量和工作效率
Q&A
Q&A Thank you
