Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum gathering 2012 shanghai 领导力与组织转型分会场演讲话题:让飞行中的敏捷软着陆(李忠利)

1,448 views

Published on

让飞行中的敏捷软着陆(李忠利)

Published in: Technology
  • Be the first to comment

Scrum gathering 2012 shanghai 领导力与组织转型分会场演讲话题:让飞行中的敏捷软着陆(李忠利)

  1. 1. 让飞行中的敏捷软着陆 --大产品研发中的敏捷导入关键点与成功案例分享 李忠利@金蝶.项目管理部 2012-06-07 Johnny Li 08/01/2010 新浪:@E路向前--李忠利
  2. 2. 软着陆
  3. 3. 维琴尼亚·萨提亚变化曲线
  4. 4. 变革曲线� 转型都会经历痛苦,在短期内可能导致绩效降 低,长期看会增长� 上面说的是必然吗?� 是否可以做到不降反升?� 最悲催的是,下去后,一直没有上来过...
  5. 5. 下面分享一个真实的案例
  6. 6. 先来点干货
  7. 7. 交付灵活性 4-6周
  8. 8. 缺陷前移明显迭代 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
  9. 9. 更多质量数据—截止到 05/09 开发 部门 大产品版本集成阶段Bug数 大产品版本集成阶段Bug Bug数 功能:集成 阶段Bug数 阶段Bug Bug数部门(A+B) 1077 104 10.36 : 1 (剔除非敏捷项目产生的bug)
  10. 10. 开发活动的时间投入分析� 管理成本大大降低--12% 管理成本大大 降低-- 成本大大降低 --1� Coding有效工作时间上升 15% Coding oding有效工作时间上升� 沟通增长6个百分点 沟通增长6
  11. 11. 敏捷团队有效工时投入曲线更为平滑
  12. 12. 产品开发:变更反而大大降低 取消任务已 项目名称 总规模 变更增加 变更减少 变更幅度 产生耗费A产品 1.0 16010 385 1675 12.87% 320.89A产品 2.0 8628 1003 1763 32.06% 193A产品专项 3.1 1988 738 324 53.45% 39 420(理想人A产品专项3.2 天--开发规模) 21 0 5.00% 04 迭代开发、拥抱变化
  13. 13. 需求渐进明细消除的浪费 � 按传统方法,这些任务将产 生20人天(两位需求给出 20人天 的估算)的工作量 � 使用敏捷方式,我们未对其 做过多的前期投入,上面估 算的投入被节省了。大致相 当于避免了项目总规模 项目总规模 1.28%的浪费 28%
  14. 14. 其他更多数据分享--同一团队 比较项 上个专项 敏捷项目功能测试开始时间 30(天) 3(天)第一个Bug出现时间 30(天)后 3(天)3周后发现Bug数量 还没开始 234(个)集成测试开始时间 80(天)后 第13个工作日 6周后
  15. 15. 你们是如何做到的?
  16. 16. 敏捷项目管理--促进价值流动� 促进高效协作和沟通� 扫除团队前进路上的任何障碍� 快速反馈,无延迟解决问题� 频繁的进行状态的检查并确保质量和效率� 管理价值流动� 迭代交付达到“潜在可发布质量”标准 17
  17. 17. 敏捷项目管理4类场景再现 • 组织各种沟通会议/机会 沟通 • 促进团队各个角色的有效协作和对迭代目标的高度一致(及时) • 保持跟邻居的有效沟通和融洽相处 • 确保站会上的发现的障碍,10点前解决,责任落实到人 执行 • 确保需求提前做好准备(不是单纯指文档) • 确保其他角色在需求阶段的深度参与(有力) • 确保敏捷的过程执行,不跑偏 • 发现瓶颈问题和关键路径。提升其优先级并加速解决 检查 • 分析每天的缺陷,必要时迅速调整,并充分沟通 分析每天的缺陷情况,必要时迅速调整相关管理实践,并充 分沟通 Show Case + 夕会(频繁) (频繁) • Mini • Mini show case + 夕会 • 调整范围,向迭代交付日期靠拢 • 调整范围,向迭代交付日期靠拢 提能 • 以老带新,提高团队的整体开发效率 • 促进业务/技能学习氛围的建设(持续)
  18. 18. 产品规划/需求� 通盘考虑,迭代交付� 从业务价值的角度讲解需求� 多样化需求表达方式,带优先级的概要列表� 明确的迭代目标� 乒乓沟通法� 第一时间进入验证测试� 重点是业务价值、渐进明细、深度沟通� 文档多少和格式,PB,Story都是浮云
  19. 19. 设计/开发--"T"型人才� 更早的介入需求阶段� 提供反馈� 重新阐述对需求的理解� 拆分需求为小任务� 深刻理解“Done”标准,自行做单测和功能测试� 原Bug优先级第一,促使开发养成高质量开发的习惯� 简单设计/TDD/CI/重构...,“选择性放弃” coding...
  20. 20. 测试--由“后保险杠”到“前车灯” � 翻讲需求 � 测试方案/设计与要点把握 � 第一时间介入测试ScrumGathering2012 � 持续进行“集成测试” � 放弃了大部分华而不实的测试用例 � 完全没有自动化测试
  21. 21. 敏捷导入感悟
  22. 22. 为高速行驶的汽车换轮胎� 帮助业务部门更好的达成业务目标� 防止“休克”式疗法� 最好的效果是“文火慢炖”� “润物细无声”是可以做到的� 敏捷导入,业务优先
  23. 23. 用大家熟悉的术语来解释敏捷� 产品待做事项-->特征包/概要需求列表� Sprint -->迭代/阶段� Epic/Theme/Feature-->业务场景...� Sprint review-->阶段评审� ......� 不用太在意叫什么名称,不叫敏捷也可以
  24. 24. 控制导入节奏 � 你不可能一步到位 � 小改进,大奖励 � 大改进,只鼓励 � “我的一小步,人类的 一大步”
  25. 25. 寻找最佳的切入点?� 先从管理流程入手,相对容易切入 � 寻找痛点 � 疏通痒点 � 贡献兴奋点� 择机引入工程实践 � 被管理层普遍忽视 � 我们欠了很多债务 � 出来混,早晚都要还的� 以上是我的经验(仅供参考)
  26. 26. 如何选择,需要您自身去判断� 更多的取决于您的环境 � 产品特点 � 目前产品研发情况 � 时间窗 � 团队进取心/规模/基础技术能力 � 管理层态度和意志 � 组织级流程 � ……
  27. 27. 强有力的领导非常关键有本事你撞我渔船试试?!!
  28. 28. 考虑更多因素� 企业文化� 原有管理模式 原有管理模式� 员工工作习惯 员工工作习惯� 学会妥协和平衡� ……
  29. 29. 软着陆,不折腾,做个靠谱的人
  30. 30. 思考:软着陆意味着什么?� 愚公移山还是翻天覆地?� 变化有一定的跳跃性和不连续性� 保持战略雄心,把握时机
  31. 31. “你们听说了,但我们做到了”!
  32. 32. MSN:tolizl@hotmail. com Weibo: E路向前--李忠利Q &A
  33. 33. Thanks

×