Devops与精益敏捷开发实现

1、精益看板，换一个方式看软件开发Devops与精益敏捷开发实现在华为一个解决方案的产品是这样的XX产品解决方案：X个大网元（200+开发）Y个小产品（50+开发）20+个部件/服务1000+人的大研发团队上海、北京、西安、深圳平台配套 第三 方云化产品A云化产品a云化产品B云化产品b云化产品d云化产品e云化产品解决方案云化产品C云化产品cXX服务通信服务XX服务LB服务XX服务 我们似乎永远在优化的道路上却又好像没有优化 我们一直在做效率提升的事情：提高各类基础设施的自动化程度、提升用例的自动化率、我们一直在做软件优化的事情：持续的做解耦、微服务拆分、技术债务消除我们一直在做管理优化的事情：各类

2、可视化看板、各类IT系统和电子流系统但有些问题一直都很难改观计划对齐困难部门协作困难层级多，风险暴露不及时，决策低效员工加班多，感受不好是我们的优化没用吗？ 我们跑数万用例，从周级变成了小时级；但用例失败后的定位时间却是按周算的我们个人级的构建时长缩短到了1分钟内；但由于跨部门的联调、沟通导致代码要在开发人员本地存几周我们通过增量编译、自动化、灵活调度让出版本的时间缩短了50%；但各类问题导致我们一个版本总要出个两三遍不是优化没用，而是优化的成果都被浪费给吃了局部的优化和整体效果并不是一回事资源效率CI各种IT 工具设计开发实现交付测试特性需求1特性需求2我很忙！ 120% ?自动化测 试用例

3、比 例提高真正的价值增加 Work Time: 60天Flow Efficiency = WorkTime/LeadTime = 60/180 30%价值流动效率 30% ！等待等待阻塞等待缺陷等 待交接 等待等待上下文切 换 等 待端到端Lead Time: 180天什么是效率？ 我们常常遇到的情况 开发团队：特性交付慢开发部的测试环境经常不好用，原因是缺乏标准化的配置缺乏专业的测试环境管理，没有空闲资源自动调度的能力，老是要协调测试资源测试团队：测试问题阻塞特性转的慢或者集中转，导致测试资源忙闲不均开发人员都忙着开发特性，没人帮忙解决问题，环境阻塞无法使用从资源效率的角度看开发团队效率低？

4、提升编码效率，人均产出要增加测试团队效率低？提升自动化程度，人均执行用例数要增加从流动效率的角度看开发去解决测试发现的问题测试把开发的测试环境也纳入到资源池进行统一管理所以我们需要一个新的视角 能看到细节，但更要看到全局。关注资源效率，但更要关注流动效率用最合理的资源解决真正的瓶颈跨过团队、部门、地域的鸿沟，建立对价值流的统一的认识1，FuR需求价值流可视化，对齐流程规范2，显示化流程规则，内建质量，增加特性验收环节4, 主动上报风险和阻塞3，进展管理可视化，代替日报5,每日站会从40分钟缩短到15分钟，关注风险和阻塞，更加高效7,与抢活干平台 有机结合6,PL、开发经理、LM每日站会，及时同

5、步信息，高效决策8,部件内FO 特性责任人 落地，团队自组织意识增强9,团队事务管理改善先来看看我们的看板 精益看板开展活动策划实践n 消除瓶颈n 加速流动 工具n Kanban Boradn Risk Reviewn Data Analytics实践n 价值流映射n 分析请求分配产能n 显示化流转规则n 限制在制品 工具n Kanban Borad第一阶段试点业务团队试点准备可视化价值流第二阶段试点业务团队试点运作可视化及管理价值流动聚焦价值、突破瓶颈、提升效率暴露问题第三阶段试点产品部试点（20+团队）其他部件看板运作可视化及管理价值流动改进研发中的浪费提升研发效率可视化管理流动实践n 拉

6、动式开发n 改进价值流 工具n Kanban Boradn Delivery Review实践n 所有实践 工具n 所有功能建立反馈循环持续改进 可视化阶段 可视化价值流分析价值项产品级、解决方案级看板团队级看板价值类型来源内容到达频率处理规则占比产品规划产品特性需求每个版本正式输入 平时会有少量插入每月进行计划一般按优先级及联调计划排列父子关系 价值类型来源内容到达频率处理规则占比产品规划产品特性需求每月一次正式输入 平时会有少量插入每月进行计划一般按优先级及联调计划排列60%测试或客户现场产品缺陷随时提出 实时安排会有严重等级情况 根据严重等级安排20%团队自身内部提出的改善性需求，如代码

7、 重构、测试优化等随时提出比较均匀受控重要但不紧急空闲时安排相对较多希望能持续有规律投入10%多种来源文档整理、迭代回顾、能力建设、 转型试点、面试招人、问题支撑 等等部分随机出现部分周期出现：迭代回顾等各不相同10%限 制 在 制 品 的 依 据可视化价值流价值流泳道设计价值注入活动 模块、测试设计 编码、SDV测试等非价值注入活动如抢活干等就绪队列已澄清 已选择缓冲队列待测试（开发Done） 待开发（设计Done）端到端的去呈现交付价值的流程，尽量在团队内展现全 景图；把部件联调、网元验收放到团队级看板跟踪，让大家关 注全局 显示化流程规则，内建质量，增加特性验收环节效果：规范各个阶段的出

8、口，特性验收，对特性的交付件有效归档发现几个特性测试不完善、检视不到位，对交付过程和结果起到明显作用管理流程阶段管理流动分层的每日看板站会站会分层团队内部轮流主持站会 效果：PL、开发经理、LM、QA每日站会，关注版本的事情，快速解决风险和阻塞，缩短决策流在不同层面关注不同的内容，从管理的角度发现新的问题两个部件项目组之间协作充分开发团队A开发团队B产品部核心团 队（开发经理、 PL、LM、QA）15min15min15min建立反馈循环根据数据反馈，建立FO制度分析：很多场景都是在等待其他部件1，联调计划不清楚，不知道什么时间点、测什么，大多数情况下可以分步骤联调2，其他部件计划变动，未能及

9、时对齐。如某FuR到准备联调的时候，其他部件却说相关需求尚未开始开发。1，已交付的FuR部件联调时间长（平均30天）2，已交付的卡片阻塞时间长（阻塞2天）4，大量卡片拥堵在部件联调部件联调现状：部件联调为现FuR开发的瓶颈点3，未交付的卡片在部件联调时间更长（中间件在部件联调共9个FuR ，联调时间超过3周的有6个FuR ，平均在部件联调时间30天）其他隐形浪费：上下文切换：开发人员在等待的同时，开始其他FuR的开发，过程中经常被联调打断出版本：需要为不同的部件在不同阶段出版本大量的沟通和协调工作重复测试：同一特性，不同部件都需要重复测试相同用例解决方案：特性FO落实组建端到端的特性团队围绕特性进行开发、测试、交付（还在策划中）效果：负责实时拉通对齐周边和自身计划端到端的风险追踪和闭环对看板数据建模，对团队情况进行改进建议分析持续改进团队事务管理改善建立中间件核心团队看板，对TOPN项目做持 续改进追踪开发经理对版本事务进行分发和追踪团队事务区分紧急程度，根据SLA进行规划按周规划填充增加就绪队列区分不同的事务类型泳道WIP