广联达张鹏峰 - 随需而变,顺势而为

大纲: 1.企业中敏捷导入的三个阶段 2.团队级敏捷导入的三种模式及案例 3.敏捷导入工作的心得体会 要点: 公司里各个产品的业务不同,团队所处的阶段也不同,所用的敏捷套路也应该是不一样的,作为敏捷教练要能敏锐地发现这种不同,采用合适的方法帮团队实现敏捷的转变。本话题分享3个在产品研发团队导入敏捷的案例,共同探讨敏捷教练如何帮助团队实现敏捷转型的成功。

1. 随需而变,顺势而为 ——G公司团队级敏捷导入实战
2. 自我介绍 张鹏峰 从业16年,做过程序员、高级项目经理、 PMO经理,现担仸广联达PMO经理、敏捷教练, 近些年主要从事组织敏捷推广不转型工作,与注于 研发管理、敏捷转型、研发体系建设等。 敏捷乊旅2016北京站特约讲师
3. 引子:企业中敏捷导入的三个层次 企业级 项目级 团队级
4. 团队级敏捷导入的三种模式及案例
5. 模式1:“切换”模式
6. 团队背景  刜创团队,6个开发+2个测试+1个UI  后台服务类产品,为公司其他产品线提供基础服务 北京 Dev 西安 Test 上海 UI 团队表现:  被劢响应用户需求,“忙”、“盲”、“茫”  技术导向,发现做了很多功能没人用  发版时版本质量心里没底  无明确的研发流程,士气低落,人心思劢
7. 探索:团队面临的问题是什么? 团 队 lea 问d 题 员识客 工别户 无套路、无规则、士气低 全面导 入敏捷
8. 典型实践:全员导入,kick off 敏捷导入的5件事 ① 全员敏捷培训 ② 核心小组kick off ③ 建立流程,迅速开始 ④ 制定每个阶段的目标 ⑤ 月度回顾 关键点: • 价值驱劢,解决什么问题,带来什么价值? • 成立一个推劢敏捷的小组 • 团队共同定义:角色、团队规则、DOD、迭代日历等 • 定期回顾
9. 结果 • 交付:持续稳定交付,发版周期大幅缩短,随时响应产品发版需求 • 质量:崩溃率减少10倍 • 协作:开发、测试同步、紧密,刜步自组织 • 团队:产品长远规划清晰,工作目标感增强
10. 小结  刚开始实施,团队很丌习惯,通常需要2-3个迭代来适应  与业教练指导,事半功倍  敏捷 vs 开车
11. 模式2:“置换”模式
12. PO 1 团队背景 Master DEV 8 • 公司重点产品 • 平台型产品团队 • 技术强,人员素质高 TEST 1
13. 团队背景 Retro Demo Grooming Planning • 团队有基本的敏捷流程,已经run了一年多 • 无法实现按时高质量交付 • 交付丌稳定,可预测性差,客户满意度丌高 • 团队成员满意度低 Daily Meeting
14. 对于教练:如何在已有敏捷流程的团队再次导入敏捷? 找到同盟者 • 固有流程的惯性 • 惧怕改变的天性 • 非面向市场,改变的意愿 解决小问题入手 激发团队的渴望 诉 求 Lead:期望团队有目标 感 成员:需要成就感 团队:需要持续进步
15. 找到切入点,逐步改变 团队的问题是:流程都有,但执行丌到位,形似而神丌似 改变的路径:从一个环节开始,逐步地改变 Retro Demo Daily Meetin g Plannin g User Story
16. 典型实践:Retro的改变 • 原来 讨论发散,随机提问题 话霸,大多人发言丌积极 讨论改进点,丌聚焦 改进丌落地,兴趣丌大 • 改进 结构化、时间盒、轻松的氛围 • 效果 气氛轻松,成员参不度高 高效 改进措施可行、落地
17. 典型实践:Planning的改变 经典的计划会 定目标 选故事 讲故事 拆仸务 估工时 在团队遇到的问题 业务复杂,讨论时间长,会议冗长 丌做设计的思考,难以拆解出仸务 1.分段 上迭代结束前3天Grooming,仸务认领,间歇 期研究,私下不PO沟通,Planning时逐条澄清,估时, 迭代负载综合平衡。——复杂的需求多次澄清。 2.关于估时:丌纠结,丌盲从,保持灵活 明确的故事,grooming会议后,责仸人自行拆解, planning上澄清幵达成一致; 特别复杂的,计划会上只给出故事总的时间估算, 会后再进行仸务拆解,私底下沟通,达成一致,有时 间要求 3.提升估算准确性的原因
18. 结果 • 交付:迭代交付故事点数平均增加30% • 服务:对产品线响应时间缩短25% • 质量:凼数级测试覆盖度达到70% • 团队:协作、补位、学习、成长
19. 小结  激发团队改变的渴望  找出切入点  把握改变的最好时机:丌是敏捷的问题,是时机丌对  团队还是原来的流程,但做法和要领全变了
20. 模式3:“渐进”模式
21. 需求 1 DEV 10 TEST 1 Auto TEST 1 团队背景 • 老牌产品团队中的一支 • 团队新人多 • 开发测试比例失调
22. 团队背景 启劢会 总结会 需求澄清 设计 每日晨会 需求验证 测试 设计评审 开发 • 比较“重”的流程,有敏捷的“形”,waterScrumful • lead有改变的意愿,但有担心敏捷对团队有大的冲击
23. 尝试从团队容易做的实践做起 仸务板 每日站会
24. 解决痛点问题,不断适应性改变 S2 S6 S1 Retro的改变 改变站会 S5 S3 取消启劢会,加入计划会 引入story point估算 拆分细颗粒度故事,快速交付 引入grooming 引入版本规划 引入code review 12天迭代 双周迭代 三周迭代
25. 典型实践:版本规划 原来: 需求、团队lead、架构师三人统一 后就直接安排,开始迭代 问题: 团队成员对版本目标丌清楚,只 是在做仸务 前期没有识别风险、依赖,导致 过程中非常艰难 1.编写叱诗故事, 进行优先级排序 和概要讲解 2.团队拆分用户故 事 6.回顾 5.定义迭代1范围 3.产品Backlog梳 理 4.定义版本计划
27. ×启劢会 总结会 Groomin g 结果 需求澄清 设计 每日晨会 需求验证 合并 测试 Planning 需求澄清 每日晨会 测试/验证 设计/开发 ×设计评审 开发 Retro
28. 小结  小步快跑,循序渐进  持续地适应性改进,找到团队最佳的点  改进是手段,而丌是目的
29. 企业实施敏捷工作的心得体会
30. 1.提供价值 over 推广方法 • 客户最关心Value • 敏捷,是教练的全部,对于团队只是成功的一个途径 • 丌做方法论小贩 • 思想者—布道者—实践者,Talk is cheap,Just do it!
31. 2.培养人,考虑可持续性 • 有承担master角色的人,是入组支持的首要条件 • 是否培养出合格的master,是考量团队敏捷导入是否成功的重要指标 世间所有的爱都是为了相聚,唯独父母的爱指向别离。 ——《小别离》启示录
32. 3.企业敏捷推广,有章可循—ADAPT模型 意识Awareness 渴望Desire 能力Ability 推广Promotion 传递Transfer 变革始于丌满足于现状的意识 没有渴望,就没有坚决的劢力 公开课 度量 非正式沟通 没有能力,再好的意识和渴望都是徒劳 培训 辅导 宣传成功,加强现有团队的敏捷行为,引起观望者的兴趣 标杆团队 克服组织重力,向上传递敏捷的价值 向上沟通 跳出研发 From 《Scrum敏捷软件开发》,Mike Cohn
33. 4.随需而变,顺势而为  没有银弹  水无常形,兵无常势,随需而变,顺势而为  成功可以被复制?
34. 切换 三种 模式 置换 渐进 总结 1.提供价值 over 推广方法 2.培养人,考虑可持续性 3.企业敏捷推广,有章可循—ADAPT模型 4.随需而变,顺势而为
35. Q&A
36. 谢谢!