More Related Content
Similar to Scrum Gathering 2012 Shanghai 领导力与组织转型分会场演讲话题:让飞行中的敏捷软着陆(李忠利)
Similar to Scrum Gathering 2012 Shanghai 领导力与组织转型分会场演讲话题:让飞行中的敏捷软着陆(李忠利) (20)
Scrum Gathering 2012 Shanghai 领导力与组织转型分会场演讲话题:让飞行中的敏捷软着陆(李忠利)
- 1. 让飞行中的敏捷软着陆
--大产品研发中的敏捷导入关键点与成功案例分享
李忠利@金蝶.项目管理部
2012-06-07
Johnny Li
08/01/2010
新浪:@E路向前--李忠利
- 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)
- 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周后
- 18. 敏捷项目管理4类场景再现
• 组织各种沟通会议/机会
沟通 • 促进团队各个角色的有效协作和对迭代目标的高度一致
(及时) • 保持跟邻居的有效沟通和融洽相处
• 确保站会上的发现的障碍,10点前解决,责任落实到人
执行 • 确保需求提前做好准备(不是单纯指文档)
• 确保其他角色在需求阶段的深度参与
(有力)
• 确保敏捷的过程执行,不跑偏
• 发现瓶颈问题和关键路径。提升其优先级并加速解决
检查 • 分析每天的缺陷,必要时迅速调整,并充分沟通
分析每天的缺陷情况,必要时迅速调整相关管理实践,并充
分沟通 Show Case + 夕会
(频繁)
(频繁) • Mini
• Mini show case + 夕会
• 调整范围,向迭代交付日期靠拢
• 调整范围,向迭代交付日期靠拢
提能 • 以老带新,提高团队的整体开发效率
• 促进业务/技能学习氛围的建设
(持续)
- 19. 产品规划/需求
� 通盘考虑,迭代交付
� 从业务价值的角度讲解需求
� 多样化需求表达方式,带优先级的概要列表
� 明确的迭代目标
� 乒乓沟通法
� 第一时间进入验证测试
� 重点是业务价值、渐进明细、深度沟通
� 文档多少和格式,PB,Story都是浮云
- 25. 控制导入节奏
� 你不可能一步到位
� 小改进,大奖励
� 大改进,只鼓励
� “我的一小步,人类的
一大步”