Johnny Li08/01/2010

让飞行中的敏捷软着陆--大产品研发中的敏捷导入关键点与成功案例分享

李忠利@金蝶.项目管理部2012-06-07

新浪：@E路向前--李忠利

软着陆

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

变革曲线

� 转型都会经历痛苦，在短期内可能导致绩效降低，长期看会增长

� 上面说的是必然吗？

� 是否可以做到不降反升？

� 最悲催的是，下去后，一直没有上来过...

下面分享一个真实的案例

先来点干货

交付灵活性 4-6周

缺陷前移明显试点部门试点部门试点部门试点部门 功能阶段功能阶段功能阶段功能阶段BugBugBugBug数数数数 小集成阶段小集成阶段小集成阶段小集成阶段

BugBugBugBug数数数数功能：小集功能：小集功能：小集功能：小集成（比值）成（比值）成（比值）成（比值）

历史专项历史专项历史专项历史专项（比值）（比值）（比值）（比值）

部门A 230（去除原有功能） 5 46 : 11 : 1

部门B 155 19 8.16 : 1

试点部门试点部门试点部门试点部门 功能阶段功能阶段功能阶段功能阶段BugBugBugBug数数数数 小集成阶段小集成阶段小集成阶段小集成阶段BugBugBugBug数数数数

功能：小集功能：小集功能：小集功能：小集成（比值）成（比值）成（比值）成（比值）

历史专项历史专项历史专项历史专项（比值）（比值）（比值）（比值）

部门A 95 3 31.7 : 11 : 1

部门B 225 18 12.5 : 1

迭代 2

迭代 1

更多质量数据—截止到 05/09

部门部门部门部门 开发开发开发开发阶段阶段阶段阶段BugBugBugBug数数数数 大产品版本集成阶段大产品版本集成阶段大产品版本集成阶段大产品版本集成阶段BugBugBugBug数数数数 功能：集成功能：集成功能：集成功能：集成

部门（A+B） 1077 104（剔除非敏捷项目产生的bug）

10.36 : 110.36 : 110.36 : 110.36 : 1

开发活动的时间投入分析

� 管理管理管理管理成本大大成本大大成本大大成本大大降低降低降低降低--------11112%2%2%2%� C C C Codingodingodingoding有效工作时间上升有效工作时间上升有效工作时间上升有效工作时间上升 15% 15% 15% 15%� 沟通增长沟通增长沟通增长沟通增长6666个百分点个百分点个百分点个百分点

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

项目名称项目名称项目名称项目名称 总规模总规模总规模总规模 变更增加变更增加变更增加变更增加 变更减少变更减少变更减少变更减少 变更幅度变更幅度变更幅度变更幅度 取消任务已取消任务已取消任务已取消任务已产生耗费产生耗费产生耗费产生耗费

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

A产品专项3.2 420（理想人天--开发规模） 21 0 5.00% 04444

迭代开发、拥抱变化

产品开发：变更反而大大降低

需求渐进明细消除的浪费

� 按传统方法，这些任务将产生20202020人天人天人天人天（两位需求给出的估算）的工作量

� 使用敏捷方式，我们未对其做过多的前期投入，上面估算的投入被节省了。大致相当于避免了项目项目项目项目总规模总规模总规模总规模1111....28282828%%%%的的的的浪费浪费浪费浪费

其他更多数据分享--同一团队

比较项比较项比较项比较项 上个专项上个专项上个专项上个专项 敏捷项目敏捷项目敏捷项目敏捷项目

功能测试开始时间 30(天) 3(天)

第一个Bug出现时间 30(天)后 3(天)

3周后发现Bug数量 还没开始 234(个)

集成测试开始时间 80（天）后 第13个工作日

6666周后周后周后周后

你们是如何做到的？

敏捷项目管理--促进价值流动

� 促进高效协作和沟通

� 扫除团队前进路上的任何障碍

� 快速反馈，无延迟解决问题

� 频繁的进行状态的检查并确保质量和效率

� 管理价值流动

� 迭代交付达到“潜在可发布质量”标准

17

敏捷项目管理4类场景再现

• 组织各种沟通会议/机会

• 促进团队各个角色的有效协作和对迭代目标的高度一致

• 保持跟邻居的有效沟通和融洽相处

沟通（及时）

• 确保站会上的发现的障碍，10点前解决，责任落实到人

• 确保需求提前做好准备（不是单纯指文档）

• 确保其他角色在需求阶段的深度参与

• 确保敏捷的过程执行，不跑偏

执行（有力）

• 以老带新，提高团队的整体开发效率

• 促进业务/技能学习氛围的建设提能（持续）

• 发现瓶颈问题和关键路径。提升其优先级并加速解决

• 分析每天的缺陷情况，必要时迅速调整相关管理实践，并充分沟通

• Mini show case + 夕会

• 调整范围，向迭代交付日期靠拢

检查（频繁）

• 发现瓶颈问题和关键路径。提升其优先级并加速解决

• 分析每天的缺陷，必要时迅速调整，并充分沟通

• Mini Show Case + 夕会

• 调整范围，向迭代交付日期靠拢

检查（频繁）

产品规划/需求� 通盘考虑，迭代交付� 从业务价值的角度讲解需求� 多样化需求表达方式，带优先级的概要列表� 明确的迭代目标� 乒乓沟通法� 第一时间进入验证测试

� 重点是业务价值、渐进明细、深度沟通

� 文档多少和格式，PB，Story都是浮云

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

� 简单设计/TDD/CI/重构...，“选择性放弃”

coding...

测试--由“后保险杠”到“前车灯”

� 翻讲需求� 测试方案/设计与要点把握� 第一时间介入测试ScrumGathering2012� 持续进行“集成测试”

� 放弃了大部分华而不实的测试用例

� 完全没有自动化测试

敏捷导入感悟

� 帮助业务部门更好的达成业务目标� 防止“休克”式疗法� 最好的效果是“文火慢炖”� “润物细无声”是可以做到的

� 敏捷导入，业务优先

为高速行驶的汽车换轮胎

� 产品待做事项-->特征包/概要需求列表

� Sprint -->迭代/阶段

� Epic/Theme/Feature-->业务场景...

� Sprint review-->阶段评审

� ......

� 不用太在意叫什么名称，不叫敏捷也可以

用大家熟悉的术语来解释敏捷

� 你不可能一步到位

� 小改进，大奖励

� 大改进，只鼓励

� “我的一小步，人类的一大步”

控制导入节奏

寻找最佳的切入点？

� 先从管理流程入手，相对容易切入�寻找痛点

�疏通痒点

�贡献兴奋点

� 择机引入工程实践�被管理层普遍忽视

�我们欠了很多债务

�出来混，早晚都要还的

� 以上是我的经验(仅供参考仅供参考仅供参考仅供参考)

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

强有力的领导非常关键

有本事你撞我渔船试试？！！

� 企业文化企业文化企业文化企业文化

� 原有原有原有原有管理模式管理模式管理模式管理模式� 员工员工员工员工工作习惯工作习惯工作习惯工作习惯

� 学会妥协和平衡学会妥协和平衡学会妥协和平衡学会妥协和平衡� ……………………

考虑更多因素

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

思考：软着陆意味着什么？

� 愚公移山还是翻天覆地？

� 变化有一定的跳跃性和不连续性

� 保持战略雄心，把握时机

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

Q & AMSN：tolizl@hotmail.comWeibo: E路向前--李忠利

Thanks