大型软件产品的敏捷案例分享

易保网络技术有限公司财产险产品线总监阳陆育 (Luyu.Ouyang@gmail.com)

2

Scrum概述

分割您的产品

根据商业价值排列优先级

商业价值

一个庞大的团队花费很长时间一次交付很多内容

拆分您的团队

多个跨职能的小团队分多个小迭代持续的交付增量的可用功能，交付过程中持续的集成、持续的改善

2010/01/01 2010/04/01分割您的时间

对过程进行持续的检视与调整

一个简单的框架

3

n 分割及组织团队

n 分割及编排计划

n 立即开始并持续改进

n 逐步克服长期挑战

大纲(contents)

4

案例实录：Team Structure

5

案例实录：Workplace Arrangement

• 把团队组织在一个开放空间中

• 尽可能在多放置白板

• 调转座椅就能开会

6

案例实录：Engineering Infrastructure

7

分享１：跨职能团队＋特性团队

n 跨职能团队：n 完成一项功能的设计，开发和测试的过程不需要进行文档化的握手过程

n 极大的减少了沟通和传递中的噪音和偏差，并且大大降低了沟通成本

n 群体决策成为可能，使得集体的智慧（Wisdom of the crowds)得以发挥n 给了每个成员更大的技术视野

n 特性团队：n 同一团队关注在同一功能模块，在同一时间段大家联合做同一个功能

n 成员间通过帮、传、带使领域知识不只是积累在文档中，而且积累在团队中，使得每个人都不是不可替代的。

n 是否一定要由Senior成员构成的团队才能发挥Scrum的作用?：n 不一定。更多的Senior的成员能提升团队的效率，但是团队的最终效率是由团队成员的配合度来决定。

n Scrum方法中大家高度协作，每个人的主动性被激发起来后，能很好的提升团队的整体作战能力，Junior成员也能很快的从Senior成员那边学到很多东西。

n 由于同一个团队关注的是相近的功能，采用ＰＰ的方法，能很好的促进学习，并能极大的营造团队的学习气氛。

8

分享２：做好开发服务是发挥作用的关键

n 工程基础设施专人专职：

q 专人负责开发测试环境的维护，持续集成体系的构建和看护

q 使得每个开发团队不需要分心于基础设施

n ＰＯ及用户故事团队全程参与，随叫随到：

q 对需求的澄清随时可以进行

q 需求人员在开发过程中即参与需求的验证和纠正

n 专职教练：

q 旁观者清，需要一个看得清楚，并一直思考的人来持续的发现问题并促进集体思考

q 专职教练能很好的帮助团队对抗团队惯性（或者叫“组织重力”）

9

n 分割及组织团队

n 分割及编排计划

n 立即开始并持续改进

n 逐步克服长期挑战

大纲(contents)

10

案例实录：Release Planning

n Body text

11

案例实录：Arrangement around the National Holiday

252423Sprint 6Review

22212019

18171615141312

11109Sprint 6Planning

8765

432130Doc review& Sprint 6 pre-planning

29Sprint 5Review

28

27262524232221

2019181716Sprint 5Planning

15Release plan

14Release plan

Sunday

Saturday

FridayThursday

Wednesday

Tuesday

Monday • 严格的保证10个工作日

的Sprint长度，节假日不例外

• 如果一个Sprint不能在固定时长内结束，在中间要进行内容的调整，但是不能延长时间

• Scrum执行成功的关键是帮助团队找到固定的节奏感

12

案例实录：Scope Control

Change requests would come from:

• End users in Sprint review and after review at

• Disagreement with solution and design

• Advise more features to product

•eBaoTech BA and PDM in implementation when

• More user stories are found to ensure business integrity

• New solutions are identified with 20%+ efforts variation

•eBaoTech Business Units when higher value features are identified

Change requests would come from:

• End users in Sprint review and after review at

• Disagreement with solution and design

• Advise more features to product

•eBaoTech BA and PDM in implementation when

• More user stories are found to ensure business integrity

• New solutions are identified with 20%+ efforts variation

•eBaoTech Business Units when higher value features are identified

Authority for Internal Control

1, Project manager as level 1 authority

2, Project Steering Board as level 2 authority

3, eBaoTech GS sub committee as final judgement

Authority for Internal Control

1, Project manager as level 1 authority

2, Project Steering Board as level 2 authority

3, eBaoTech GS sub committee as final judgement

Change Adopting

Urgent cases are handled immediately and the impacts will be fixed afterwards;

Normal cases are handled before each sub-release

Change Adopting

Urgent cases are handled immediately and the impacts will be fixed afterwards;

Normal cases are handled before each sub-release

External Change Request Handling

Following the agreement made per project with co-developer

External Change Request Handling

Following the agreement made per project with co-developer

13

分享３：基于”客户价值“的计划

n 编排目标，而非编排任务：

q 先把每一个Subrelease和每一个Sprint的业务目标定下来，根据业务目标来分解用户故事。

q 永远先做优先级高的事情，优先级低的事情由用户故事团队持续的与客户协商。

n 及早开始，逐步清晰，及时调整：

q 让用户故事的细化与开发并行起来，尽早开始开发，为开发工作腾出更多的时间

q 使用Sprint0来解决大的方案和技术风险q 在每个Sprint中预留１０％～２０％的时间准备下一个Sprint

n 不断调整，不停检视：

q 每个Subrelease结束前一个Sprint重新进行Release planning，进行大的变更管理q 每个Sprint review结束后，调整Product backlog的内容及优先级

14

n 分割及组织团队

n 分割及编排计划

n 立即开始并持续改进

n 逐步克服长期挑战

大纲(contents)

15

案例实录：Burndown of a team in sprint 1

• 猜猜这个Sprint中发生了什么事情

• 分析一下早期的Sprint为什么会是这样

16

案例实录：Burndown of a team in sprint 5

• 猜猜这个Sprint中发生了什么事情

• 分析一下有了一些新的尝试后的Sprint为什么会是这样

17

案例实录：Burndown of a team in sprint 8

• 猜猜这个Sprint中发生了什么事情

• 分析一下一个理想的Sprint的执行状况应该是什么样子

18

案例实录：Define the DOD

Master of testing

20% cases automated (as a starting point, we will increase the ratio a bit by a bit)

Automation testing

Master assigned100% validated against the

standard from AndrewBasic quality criteria passed

Product Owner Representative

100% demo scenario coveredProduct owner acceptance testing passed

Master assigned100% in QA reportTesting regressed at integrated Testing environment

Master assigned100% in QA reportFunctional testing cases 100% pass at Dev

environment

Master assignedMore than 0 in QA reportTest cases in TD

Master of engineering

Enforced at code check-inAutomated code check/review

Master(not defined yet, we will define

no late than sprint 5)Unit testing at local (by Java or by other method)

MasterDemo feature in Testing environmentDeliver to integrated Testing environment

Master100% CQ status as "reviewed"Code complete

OwnerDefinition of DoneAspect

19

分享４：改进，改进，再改进

n 定义清晰的ＤＯＤ：

q DOD是一种Commitment，而不是一种监管手段q Owner of DOD的使命是让团队理解，而不是强迫团队执行q 质量来自于团队意识，而不是来自于测试

n 让团队自学习：

q Sprint不是微型的瀑布，让团队成员自己打配合q 尽量多的ＰＰ

q 允许团队犯错误，帮助团队分析原因

n 稳定然后再提高：

q Scrum不会加快开发速度，团队配合效率的提高才能提高速度q 假设一个Velocity然后不断的较正q 尽量确保团队稳定

20

n 分割及组织团队

n 分割及编排计划

n 立即开始并持续改进

n 逐步克服长期挑战

大纲(contents)

21

逐步克服长期挑战

n 技术债务

q 慢慢的补齐欠缺的单元测试及自动化

q 定期的组织重构活动

q 每个Sprint的review中加入defect review and summarize

n 协调敏捷的方法与ＰＭＯ监管

q 争取公司管理层的认同

q 将用户故事测算转化成传统PMP的测算值q 鼓励PMO参与Sprint review

n 打造高效的团队

q 团队发展的三个层次:forming, storming, performingq 给团队适中的压力

q 组织长效的培训计划，鼓励学习与分享

q 保持团队稳定

22

nThanks!