如何建设敏捷研发团队

1. 周 辉
willzhou@live.com
2012.05.03

2. 核心价值观 VALUE
ž 个体和互动 流程和工具
ž 可用的产品 详尽的文档
ž 用户配合 合同谈判
ž 响应变化 遵循计划

3. 基本角色 ROLE
ž 产品经理 Product Owner
对产品的价值负责
ž 团队教练 Scrum Master
保证团队运作敏捷和高效
ž 团队成员 Scrum Team
自组织地完成项目中的各个任务

4. 项目工具 ARTIFACT
ž 产品功能表 Product Backlog
ž 迭代任务表 Sprint Backlog
ž 燃尽图 Burn Down Chart
ž 团队障碍表 Defect Backlog

5. 重要会议 MEETINGS
ž 迭代计划会议 Sprint Planning Meeting
ž 每日站立会 Daily Scrum Meeting
ž 迭代评审会议 Sprint Review Meeting
ž 反思会 Retrospection Meeting

6. 项目过程示意图
初始阶段 计划阶段 冲刺阶段 发布阶段

7. 项目工具
ARTIFACT

8. 产品功能表 Product Backlog
ž 列表是不断更新的，项目过程中任何时候都
有可能增加或者删除故事点
ž 每个故事对应一个重要等级，较高等级的应
首先予以实施
ž 较低等级的，描述可以粗糙一点，因为在级
别提高之前可能只对产品负责人有意义
ž 表格应随着时间不断更新，而且越来越精确

9. 产品功能表样例
NOTES
ID Product Backlog
相关信息说明，一些解
统一标识符，自增 释或注解等
长的数字而已
PO负责
1
USER STORY
2
3
HOW TO DEMO
4
初步描述了如何进行该
用户故事，也就是
功能的示范
5
要实现的功能 6
7
8
9
10
PO负责 11
12
团队负责
13
IMPORTANCE 14
15
ESTIMATE
重要点数，只用于 16 团队的初步估算，表示
区分故事之间的重 17
18
完成该故事的工作量。
要程度，但数值差 19 单位d表示day，如果单
倍数不表示重要程 20
位是h，则表示hour。
度的倍数 1d=8h。
21
22

10. 迭代任务表 Sprint Backlog
ž 列出了冲刺周期中团队需要完成的用户故事
ž 每个用户故事，将会分解为多个任务（非常
技术化），并由Scrum团队的成员领取完成
ž 团队应充分协作，自组织完成每个冲刺阶段
的各个任务
ž 每日更新Sprint Backlog和Burn Down Chart

11. 迭代任务列表样例
Product Backlog
Sprint Backlog: PROJECT - Sprint1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
180"
160"
140"
Sprint
120"
100"
80"
60"
40"
制定迭代任务表一般都比较
20"
0"
1" 2" 3" 4" 5" 6" 7" 8" 9" 10"
难，但是对于团队非常重要！
Sprint
计划会的主要任务就是完善、
精确这个表！

12. 迭代开发期间特点
ž 一旦迭代开始，任何人不能改变迭代期间需
要实现的功能
ž 开发人员应根据最具技术性或最符合团队状
况的顺序，来完成迭代周期中的各个任务
ž 团队成员自己更新Sprint Backlog
ž Burn Down Chart应根据剩余时间点自动更
新绘制

13. 重要会议
MEETINGS

14. 关于迭代计划会议
ž 第⼀一个计划会议，主要确定Sprint的目标
以及Sprint Backlog
ž 第二个计划会议，确定Sprint Backlog中
每个任务的承担人，并根据实际情况裁减
Sprint Backlog，生成最终的Sprint
Backlog

15. 关于每日站立会（15分钟）
ž 昨天你完成了哪些工作？
ž 今天你打算做什么？
ž 完成你的目标是否存在什么障碍？

16. 关于评审会
ž 尽量邀请所有有关人员，向他们演示Sprint的新成果
ž 最终反馈将会由Product Owner和/或Scrum Master记
录下来
ž 不要花太多时间准备演示工作
ž 关注于业务层面，而不是技术细节
ž 不要演示bug及其修复，不要演示微不足道的特性

17. 关于反思会
ž 分析Sprint中的成功经验和遇到的障碍
ž 记录下做的不错的方面
ž 遇到的障碍，加入到障碍Backlog列表中

18. 进一步说明
MORE

19. 关于“人”的几个重要说明
ž 一个产品的Scrum团队，人数最佳范围为3~8人（不包括
产品负责人）
ž 团队教练（Scrum Master）并不是团队的主管，是专门
负责为团队扫除障碍，保障团队互动、敏捷、自组织的
人
ž Scrum Master同时也是团队中的开发员
ž Scrum团队内部不需要主管，因其是自组织方式协作的
ž 团队成员不分角色，都是多面手，每一个人都有参与所
有方面的权力，没有专门的编码人员和设计人员之类

20. 关于极限编程
ž 结对编程
两人坐在⼀一起同时分析、设计、测试、开发
ž 测试驱动开发
在改变任何代码之前先编写一个自动化测试
ž 持续集成
不超过2个小时就对改变的地方进行一次自动集成和测试
ž 代码重构
不改变功能的前提下，改善软件的质量和性能，提高代码
的可读性

21. 项目介绍
PROJECTS
(略)

22. 拥抱变化！持续卓越！

23. 联系我
ž http://www.linkedin.com/in/willzhou
ž http://weibo.com/willzhouhui
ž willzhou@live.com

24. 谢谢！