1. 大型软件产品的敏捷案例分享
易保网络技术有限公司 财产险产品线总监
阳陆育 (Luyu.Ouyang@gmail.com)

2. Scrum概述 拆分您的团队 一个简单的框架
分割您的产品
一个庞大的团队花费很长时间一次交付很多内容
多个跨职能的小团队分多个小迭代持续的交付增量的可用功能，
交付过程中持续的集成、持续的改善
商 对过程进行持续的
业 分割您的时间 检视与调整
价 2010/01/01 2010/04/01
值
根据商业价值
排列优先级
2

3. 大纲(contents)
n 分割及组织团队
n 分割及编排计划
n 立即开始并持续改进
n 逐步克服长期挑战
3

4. 案例实录：
Team Structure
4

5. 案例实录：
Workplace Arrangement
• 把团队组织在一个开放
空间中
• 尽可能在多放置白板
• 调转座椅就能开会
5

6. 案例实录：
Engineering Infrastructure
6

7. 分享１：跨职能团队＋特性团队
n 跨职能团队：
n 完成一项功能的设计，开发和测试的过程不需要进行文档化的握手过程
n 极大的减少了沟通和传递中的噪音和偏差，并且大大降低了沟通成本
n 群体决策成为可能，使得集体的智慧（Wisdom of the crowds)得以发挥
n 给了每个成员更大的技术视野
n 特性团队：
n 同一团队关注在同一功能模块，在同一时间段大家联合做同一个功能
n 成员间通过帮、传、带使领域知识不只是积累在文档中，而且积累在团队中，使得每个人
都不是不可替代的。
n 是否一定要由Senior成员构成的团队才能发挥Scrum的作用?：
n 不一定。更多的Senior的成员能提升团队的效率，但是团队的最终效率是由团
队成员的配合度来决定。
n Scrum方法中大家高度协作，每个人的主动性被激发起来后，能很好的提升团
队的整体作战能力，Junior成员也能很快的从Senior成员那边学到很多东西。
n 由于同一个团队关注的是相近的功能，采用ＰＰ的方法，能很好的促进学习，
并能极大的营造团队的学习气氛。
7

8. 分享２：做好开发服务是发挥作用的关键
n 工程基础设施专人专职：
q 专人负责开发测试环境的维护，持续集成体系的构建和看护
q 使得每个开发团队不需要分心于基础设施
n ＰＯ及用户故事团队全程参与，随叫随到：
q 对需求的澄清随时可以进行
q 需求人员在开发过程中即参与需求的验证和纠正
n 专职教练：
q 旁观者清，需要一个看得清楚，并一直思考的人来持续的发现问题并促进集体思考
q 专职教练能很好的帮助团队对抗团队惯性（或者叫“组织重力”）
8

9. 大纲(contents)
n 分割及组织团队
n 分割及编排计划
n 立即开始并持续改进
n 逐步克服长期挑战
9

10. 案例实录：
Release Planning
n Body text
10

11. 案例实录：
Arrangement around the National Holiday
Monda Tuesd Wedn Thurs Friday Saturd Sunda
y ay esday day ay y • 严格的保证10个工作日
14 15 16 17 18 19 20 的Sprint长度，节假日
Release Release Sprint 5
plan plan Planning 不例外
21 22 23 24 25 26 27
• 如果一个Sprint不能在
固定时长内结束，在中
28 29 30 1 2 3 4
Sprint 5 Doc 间要进行内容的调整，
Review review 但是不能延长时间
& Sprint 6
pre-
planning
• Scrum执行成功的关键
5 6 7 8 9 10 11
是帮助团队找到固定的
Sprint 6 节奏感
Planning
12 13 14 15 16 17 18
19 20 21 22 23 24 25
Sprint 6
Review
11

12. 案例实录：
Scope Control
Authority for Internal
Authority for Internal External
External
Control
Control Change
Change
Change requests would come from:
Change requests would come from: Request
Request
1, Project manager as
1, Project manager as
level 1 authority Handling
Handling
level 1 authority
• End users in Sprint review and after
• End users in Sprint review and after 2, Project Steering Board Following the
Following the
2, Project Steering Board
review at
review at as level 2 authority agreement
agreement
as level 2 authority
made per
made per
• Disagreement with solution and
• Disagreement with solution and 3, eBaoTech GS sub
3, eBaoTech GS sub project with
project with
design
design committee as final
committee as final co-developer
co-developer
• Advise more features to product
• Advise more features to product judgement
judgement
•eBaoTech BA and PDM in implementation
•eBaoTech BA and PDM in implementation
when
when
• More user stories are found to
• More user stories are found to
ensure business integrity
ensure business integrity Change Adopting
Change Adopting
• New solutions are identified with
• New solutions are identified with Urgent cases are
Urgent cases are
20%+ efforts variation
20%+ efforts variation handled immediately
handled immediately
•eBaoTech Business Units when higher
•eBaoTech Business Units when higher and the impacts will be
and the impacts will be
value features are identified
value features are identified fixed afterwards;
fixed afterwards;
Normal cases are
Normal cases are
handled before each
handled before each
sub-release
sub-release
12

13. 分享３：基于”客户价值“的计划
n 编排目标，而非编排任务：
q 先把每一个Subrelease和每一个Sprint的业务目标定下来，根据业务目标来分解用
户故事。
q 永远先做优先级高的事情，优先级低的事情由用户故事团队持续的与客户协商。
n 及早开始，逐步清晰，及时调整：
q 让用户故事的细化与开发并行起来，尽早开始开发，为开发工作腾出更多的时间
q 使用Sprint0来解决大的方案和技术风险
q 在每个Sprint中预留１０％～２０％的时间准备下一个Sprint
n 不断调整，不停检视：
q 每个Subrelease结束前一个Sprint重新进行Release planning，进行大的变更管理
q 每个Sprint review结束后，调整Product backlog的内容及优先级
13

14. 大纲(contents)
n 分割及组织团队
n 分割及编排计划
n 立即开始并持续改进
n 逐步克服长期挑战
14

15. 案例实录：
Burndown of a team in sprint 1
• 猜猜这个Sprint中发生了什么事情
• 分析一下早期的Sprint为什么会是这样
15

16. 案例实录：
Burndown of a team in sprint 5
• 猜猜这个Sprint中发生了什么事情
• 分析一下有了一些新的尝试后的Sprint为什么会是这样
16

17. 案例实录：
Burndown of a team in sprint 8
• 猜猜这个Sprint中发生了什么事情
• 分析一下一个理想的Sprint的执行状况应该是什么样子
17

18. 案例实录：
Define the DOD
Aspect Definition of Done Owner
Code complete 100% CQ status as "reviewed" Master
Deliver to integrated Testing environment Demo feature in Testing environment Master
(not defined yet, we will define
Unit testing at local (by Java or by other method) Master
no late than sprint 5)
Master of
Automated code check/review Enforced at code check-in
engineering
Test cases in TD More than 0 in QA report Master assigned
Functional testing cases 100% pass at Dev
100% in QA report Master assigned
environment
Testing regressed at integrated Testing environment 100% in QA report Master assigned
Product Owner
Product owner acceptance testing passed 100% demo scenario covered Representat
ive
100% validated against the
Basic quality criteria passed Master assigned
standard from Andrew
20% cases automated
(as a starting point, we will Master of
Automation testing
increase the ratio a bit by a testing
bit) 18

19. 分享４：改进，改进，再改进
n 定义清晰的ＤＯＤ：
q DOD是一种Commitment，而不是一种监管手段
q Owner of DOD的使命是让团队理解，而不是强迫团队执行
q 质量来自于团队意识，而不是来自于测试
n 让团队自学习：
q Sprint不是微型的瀑布，让团队成员自己打配合
q 尽量多的ＰＰ
q 允许团队犯错误，帮助团队分析原因
n 稳定然后再提高：
q Scrum不会加快开发速度，团队配合效率的提高才能提高速度
q 假设一个Velocity然后不断的较正
q 尽量确保团队稳定
19

20. 大纲(contents)
n 分割及组织团队
n 分割及编排计划
n 立即开始并持续改进
n 逐步克服长期挑战
20

21. 逐步克服长期挑战
n 技术债务
q 慢慢的补齐欠缺的单元测试及自动化
q 定期的组织重构活动
q 每个Sprint的review中加入defect review and summarize
n 协调敏捷的方法与ＰＭＯ监管
q 争取公司管理层的认同
q 将用户故事测算转化成传统PMP的测算值
q 鼓励PMO参与Sprint review
n 打造高效的团队
q 团队发展的三个层次:forming, storming, performing
q 给团队适中的压力
q 组织长效的培训计划，鼓励学习与分享
q 保持团队稳定
21

22. n Thanks!
22