让飞行中的敏捷软着陆（李忠利）

1. 让飞行中的敏捷软着陆
--大产品研发中的敏捷导入关键点与成功案例分享
李忠利@金蝶.项目管理部
2012-06-07
Johnny Li
08/01/2010
新浪：@E路向前--李忠利

3. 软着陆

4. 维琴尼亚·萨提亚变化曲线

5. 变革曲线
� 转型都会经历痛苦，在短期内可能导致绩效降
低，长期看会增长
� 上面说的是必然吗？
� 是否可以做到不降反升？
� 最悲催的是，下去后，一直没有上来过...

6. 下面分享一个真实的案例

7. 先来点干货

8. 交付灵活性 4-6周

9. 缺陷前移明显
迭代 1 试点部门 功能阶段Bug数
功能阶段Bug
Bug数 小集成阶段 功能：小集 历史专项
Bug数
Bug数 成（比值） （比值）
部门A 230（去除原有功能） 5 46 : 1
1 : 1
部门B 155 19 8.16 : 1
迭代 2 试点部门 功能阶段Bug数
功能阶段Bug
Bug数 小集成阶段 功能：小集 历史专项
Bug数
Bug数 成（比值） （比值）
部门A 95 3 31.7 : 1
1 : 1
部门B 225 18 12.5 : 1

10. 更多质量数据—截止到 05/09
开发
部门 大产品版本集成阶段Bug数
大产品版本集成阶段Bug
Bug数 功能：集成
阶段Bug数
阶段Bug
Bug数
部门（A+B） 1077 104 10.36 : 1
（剔除非敏捷项目产生的bug）

11. 开发活动的时间投入分析
� 管理成本大大降低--12%
管理成本大大 降低--
成本大大降低 --1
� Coding有效工作时间上升 15%
Coding
oding有效工作时间上升
� 沟通增长6个百分点
沟通增长6

12. 敏捷团队有效工时投入曲线更为平滑

13. 产品开发：变更反而大大降低
取消任务已
项目名称 总规模 变更增加 变更减少 变更幅度
产生耗费
A产品 1.0 16010 385 1675 12.87% 320.89
A产品 2.0 8628 1003 1763 32.06% 193
A产品专项 3.1 1988 738 324 53.45% 39
420（理想人
A产品专项3.2 天--开发规模）
21 0 5.00% 04
迭代开发、拥抱变化

14. 需求渐进明细消除的浪费
� 按传统方法，这些任务将产
生20人天（两位需求给出
20人天
的估算）的工作量
� 使用敏捷方式，我们未对其
做过多的前期投入，上面估
算的投入被节省了。大致相
当于避免了项目总规模
项目总规模
1.28%的浪费
28%

15. 其他更多数据分享--同一团队
比较项 上个专项 敏捷项目
功能测试开始时间 30(天) 3(天)
第一个Bug出现时间 30(天)后 3(天)
3周后发现Bug数量 还没开始 234(个)
集成测试开始时间 80（天）后 第13个工作日
6周后

16. 你们是如何做到的？

17. 敏捷项目管理--促进价值流动
� 促进高效协作和沟通
� 扫除团队前进路上的任何障碍
� 快速反馈，无延迟解决问题
� 频繁的进行状态的检查并确保质量和效率
� 管理价值流动
� 迭代交付达到“潜在可发布质量”标准
17

18. 敏捷项目管理4类场景再现
• 组织各种沟通会议/机会
沟通 • 促进团队各个角色的有效协作和对迭代目标的高度一致
（及时） • 保持跟邻居的有效沟通和融洽相处
• 确保站会上的发现的障碍，10点前解决，责任落实到人
执行 • 确保需求提前做好准备（不是单纯指文档）
• 确保其他角色在需求阶段的深度参与
（有力）
• 确保敏捷的过程执行，不跑偏
• 发现瓶颈问题和关键路径。提升其优先级并加速解决
检查 • 分析每天的缺陷，必要时迅速调整，并充分沟通
分析每天的缺陷情况，必要时迅速调整相关管理实践，并充
分沟通 Show Case + 夕会
（频繁）
（频繁） • Mini
• Mini show case + 夕会
• 调整范围，向迭代交付日期靠拢
• 调整范围，向迭代交付日期靠拢
提能 • 以老带新，提高团队的整体开发效率
• 促进业务/技能学习氛围的建设
（持续）

19. 产品规划/需求
� 通盘考虑，迭代交付
� 从业务价值的角度讲解需求
� 多样化需求表达方式，带优先级的概要列表
� 明确的迭代目标
� 乒乓沟通法
� 第一时间进入验证测试
� 重点是业务价值、渐进明细、深度沟通
� 文档多少和格式，PB，Story都是浮云

20. 设计/开发--"T"型人才
� 更早的介入需求阶段
� 提供反馈
� 重新阐述对需求的理解
� 拆分需求为小任务
� 深刻理解“Done”标准，自行做单测和功能测试
� 原Bug优先级第一，促使开发养成高质量开发的习惯
� 简单设计/TDD/CI/重构...，“选择性放弃”
coding...

21. 测试--由“后保险杠”到“前车灯”
� 翻讲需求
� 测试方案/设计与要点把握
� 第一时间介入测试ScrumGathering2012
� 持续进行“集成测试”
� 放弃了大部分华而不实的测试用例
� 完全没有自动化测试

22. 敏捷导入感悟

23. 为高速行驶的汽车换轮胎
� 帮助业务部门更好的达成业务目标
� 防止“休克”式疗法
� 最好的效果是“文火慢炖”
� “润物细无声”是可以做到的
� 敏捷导入，业务优先

24. 用大家熟悉的术语来解释敏捷
� 产品待做事项-->特征包/概要需求列表
� Sprint -->迭代/阶段
� Epic/Theme/Feature-->业务场景...
� Sprint review-->阶段评审
� ......
� 不用太在意叫什么名称，不叫敏捷也可以

25. 控制导入节奏
� 你不可能一步到位
� 小改进，大奖励
� 大改进，只鼓励
� “我的一小步，人类的
一大步”

26. 寻找最佳的切入点？
� 先从管理流程入手，相对容易切入
� 寻找痛点
� 疏通痒点
� 贡献兴奋点
� 择机引入工程实践
� 被管理层普遍忽视
� 我们欠了很多债务
� 出来混，早晚都要还的
� 以上是我的经验(仅供参考)

27. 如何选择，需要您自身去判断
� 更多的取决于您的环境
� 产品特点
� 目前产品研发情况
� 时间窗
� 团队进取心/规模/基础技术能力
� 管理层态度和意志
� 组织级流程
� ……

28. 强有力的领导非常关键
有本事你撞我渔船试试？！！

29. 考虑更多因素
� 企业文化
� 原有管理模式
原有管理模式
� 员工工作习惯
员工工作习惯
� 学会妥协和平衡
� ……

30. 软着陆，不折腾，做个靠谱的人

31. 思考：软着陆意味着什么？
� 愚公移山还是翻天覆地？
� 变化有一定的跳跃性和不连续性
� 保持战略雄心，把握时机

32. “你们听说了，但我们做到了”！

33. MSN：tolizl@hotmail.
com
Weibo: E路向前--李忠利
Q &A

34. Thanks