欧兰辉、刘小林 中国DevOps社区峰会2022·武汉 峰会2022·武汉 数字化转型存在诸多痛点 项目2 项目1 项目2二期 项目3 项目3三期 项目集1需求 项目3二期 项目3四期项目集 …… 技术改造…… 时间痛点始点痛点改进痛点规模痛点成果痛点 转型需要时间 给转型工作提供的时间不多 书上说的都有次序但是每个项目的情况各有不同 团队需要改进,但是不能降低产能和无视项目目标,特别是项目的时间压力 中国DevOps社区峰会2022·武汉 团队规模庞大,靠单个团队改进需要可以复制的实践 转型过程复杂,涉及人员众多,影响因素相关关联,如何证明实践的有效性。 重拾敏捷价值观和原则建立转型策略 端到端即时极简 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观: 个体和互动over流程和工具可用的软件over详尽的文档客户协作over合同谈判 响应变化over遵循计划 也就是说,尽管右项有其价值,我们更重视左项的价值。 8 可持续,稳定的开发速度 7衡量进度 可工作的软件 1目标尽早持续有价值 满足客户 2欢迎变更 帮助客户建立竞争优势 3要经常 周期越短越好 4要 业务、开发在一起 6 面对面最有效 10 最佳的架构、需求设计出自自组织团队 11简洁尽量减少不必要的工作 5要 激励人员环境和支持相信他们能完成任务 9卓越技术精益求精 设计不断完善 12调整行为 定期回顾和反省 左移右移 探索稳定 发现问题解决问题团队磨合 固化流程形成战斗力 中国DevOps社区峰会2022·武汉 极简质效:从0到1的团队敏捷度 团队敏捷度 存在感 进展感(P) 目标感(O)成就感 参与感 协作感(Q) 天鹅拉车 资源不限量供应 击鼓传花需要优化合作 团队的生长上限,生命体成长 中国DevOps社区峰会2022·武汉 落地三板斧 调结构稳节奏定产能 中国DevOps社区峰会2022·武汉 落地三板斧 第1步调结构 中国DevOps社区峰会2022·武汉 落地三板斧 第1步调结构 业务端到端流程 真实的用户测试真实的用户测试 目标 敏捷 传统流程 用户拒绝的功能 传统方式的应用错误 能力调整 敏捷的应用错误 第一次全量交付 中国DevOps社区峰会2022·武汉 IT端到端交付 落地三板斧 第1步调结构解决方案架构师 项目经理 测试 开发 产品 业务部门 产品负责人开发负责人测试负责人 团队目标:拉通业务端到端的目标诉求以及研发小队的端到端交付过程目标DoD:需求完成到待发布 (Readytorelease)方可计数 业务代表 业务代表 人员固定 团队统一负责人负责端到端交付 产品、研发、测试整合 测试 人员相对稳定且专职 人员角色、职责清晰 人数限制(非强制)7±2 近距离现场沟通 测试 开发 产品 业务部门 开发 产品 业务部门 业务代表 横向拉通业务,决定在哪个领域进行功能实施 项目相关决策 拉通业务端到端流程,及跨团队需求优先级 产品相关技能支持和决策产品相关规范要求 横向拉通跨系统技术沟通、技术相关技能支持和决策、技术相关规范要求 横向拉通跨系统测试工作计划、数据、用例等 测试相关技能支持和决策测试相关规范要求 中国DevOps社区峰会2022·武汉 落地三板斧 第1步调结构 DoRDoD 如一个通用的DoR条件包括: •业务逻辑描述清晰 •业务流程已明确 •UI/UE已准备(可以是手绘原型,必须能保证可以说明问题) •上下游依赖系统已经沟通并确定联调时间 •数据规范已确认(若涉及) •详细设计已完成评审 •测试用例已准备并完成评审 自研项目或人力外包项目的DoD条件: •编码结束 •单功能移测、修复完 •测试回归测试完成供应商项目: •编码结束 •单功能移测、修复完 •UAT环境更新,确保本公司和业务方可以接入 开发在迭代第一天可以进入编码的状态,团队的DoR内容还缺少什么内容 迭代完成的内容可以随时演示或上线,团队的DoD条件还缺少什么内容 一次解决一个主要问题动态调整 中国DevOps社区峰会2022·武汉 落地三板斧 第2步稳节奏 中国DevOps社区峰会2022·武汉 落地三板斧 第2步稳节奏 两周一次迭代,每迭代发布一个版本,发布窗口为周一晚(or周四晚),目标:不停机发布 PO:规划“做对的事” 迭代N+1需求梳理会,原型设计封版 Week1Week2 迭代NUI设计封版迭代N评审会迭代N计划会 Week1Week2 Team:实现“把事做对” 当前迭代N 迭代N发布 需求梳理会:产品给团队讲下一个迭代需求计划会:研发给产品和测试反讲需求 评审会:团队给产品和业务方show新功能回顾会:从交付过程角度回顾 迭代N代码封版 迭代N回顾会:按需开 中国DevOps社区峰会2022·武汉 落地三板斧 第2步稳节奏 极简活动 需求梳理UI设计封板研发代码封板 迭代会议 迭代会议 中国DevOps社区峰会2022·武汉12 落地三板斧 第2步稳节奏 需求梳理会 会 晨/夕会站会迭代 业务演示会 中国DevOps社区峰会2022·武汉 落地三板斧 第2步稳节奏 1 传统 目标: 晨会: 根据进展排定今明两天需要交付的功能点/故事 迭代初期没有可视化的进展 按角色传递 依赖于最后联调成功,一成俱成,一败全损 业务到最后才能发现问题 ?% 延期 或下一迭代 需求拆细数据化跟进 敏捷 跟进进展 跟进离目标完成的距离 发现协作中的问题并进行优化 迭代的每一天都有进展 按需求价值传递 按故事移测,随时完成及时交付业务验证 可以上线一部分 100 夕会: 检查交付情况,团队根据进展进行治理决策 统一Showcase 91 DoD 不是观点说话,事实说话不是感觉说话,数据说话 中国DevOps社区峰会2022·武汉 落地三板斧 第2步稳节奏 •今天计划进行哪些用户故事的开发,可以Showcase几个 •有哪些风险项,相关的应对措施是什么 •其它需要对齐的问题 在晨会上,收集信息但不进行讨论。讨论应该只发在需要讨论的人员之间。 夕会根据晨会的安排检视完成情况,比如Showcase的需求个数,BUG数,期待待办事项的跟进情况 小组 待办事项: 1、订单线1个需求待与业务确认,请……跟进 2、支撑线新增需求请……尽快评估工时小组1 1、开发计划showcase2个卡片 …… 今日计划showcase点共……个,计划修改bug……个,bug剩余总量……个 风险/问题(研发、测试、运维): …… 待办事项: …… 团队项目目标 团队 小组故事数 故事故事完成 交付情况和风 人险情况 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 Functionality Traditional Fixed Variable Time OPQ Fixed Time Variable DSDM Resources TimeResources FunctionalityResources Functionality 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 澄清调研场景汇总 蓝图初版 蓝图定稿业务确认 产品PRD开发SITUAT上线 新建需求分析中需求设计中需求已确认待开发开发中开发完成测试中待发布已发布 问题识别 目标 行动 抓手 相关事项 中国DevOps社区峰会2022·武汉 落地三板斧 第3步定产能 基础理论实践场景演练复盘答疑 •敏捷价值观与原则 •SCRUM框架 •敏捷快速落地法介绍 •看板基础理论 •行业场景讲解(金融科技/生产制造……) •使用故事地图建立目标感 •MVP概念、建立MVP原则 •故事拆分 •敏捷仪式 •项目管理方式 •产品管理方式 •团队组建(团队容量计算*) •迭代0:版本规划(DoD及DoR,估算工具*) •迭代1:展示迭代计划结果 (迭代计划、迭代回顾) •迭代2:过程改进和协作优化* •迭代3:迭代过程总结和度量机制*(敏捷度量指标如何选取*、效能对团队的意义*) •课程总结和回顾 •落地实践共创* •答疑(针对行业场景定制) 依托工具,直接赋能,不断优化和打造支撑能力 中国DevOps社区峰会2022·武汉 落地策略 端到端及时极简 中国DevOps社区峰会2022·武汉 结果和反思 团队敏捷度 落地三板斧 落地策略 快稳 导入一个团队从3个套路月缩短成3个迭代 好 战略落地 多 可复制,规模化 赞 效果,团队反馈,管理反馈,业务反馈 时间痛点始点痛点改进痛点规模痛点成果痛点 转型需要时间 给转型工作提供的时间不多 书上说的都有次序但是每个项目的情况各有不同 团队需要改进,但是不能降低产能和无视项目目标,特别是项目的时间压力 中国DevOps社区峰会2022·武汉 团队规模庞大,靠单个团队改进需要可以复制的实践 转型过程复杂,涉及人员众多,影响因素相关关联,如何证明实践的有效性。 Q&A 中国DevOps社区峰会2022·武汉