DevOps在企业内部实施时 ， 要形成以企业高层如：CIO ， 业务部门和科技部门共同组成的DevOps转型小组 ， DevOps转型会使得之前的组织结构发生很大的变化 ， 将之前的大部队作战方式 ， 转型为一个一个的小团体进行作战 ， 这样会更加机动灵活 。

• 工具的坑：让需求流动起来才能更大程度发挥工具的价值

DevOps工具链的建设 ， 是实施DevOps转型的第一步 ， 有很多人认为 ， 有了工具就实现了DevOps 。
其实 ， 一般的工具都只是满足某一个阶段的需求 。 比如 ， 用jenkins来做持续集成 ， 用Jira来做项目管理 ， 用gitlab来管理源代码 。 有了工具并不能说就实现了DevOps ， 虽然通过工具确实能提高某些阶段的效率 ， 但DevOps最终的目标是为了提高企业整体研发流程的效率和质量 。
因此 ， 我们需要让需求流动起来 ， 并通过不断的反馈和持续改进优化 ， 才能最终实现既快速 ， 且高质量的价值交付 。
四、关于DevOps转型之路的思考 1、经典的DevOps三步工作法 来自《DevOps实践指南》的经典三步工作法：
第一步：流动原则
实现开发到运维的工作快速地从左向右流动 。 为了最大程度地优化工作流 ， 需要将工作可视化 ， 减少每批次大小和等待间隔 ， 通过内建质量杜绝向下游传递缺陷 ， 并持续地优化全局目标 。
第二步：反馈原则
在从右向左的每个阶段中 ， 应用持续、快速的工作反馈机制 。 通过反馈机制 ， 防止问题复发 ， 并能缩短问题检测周期 ， 实现快速修复 。 能够创造出组织学习与改进的机会 。
第三步：持续学习和实验原则
建立具有创意和高可信度的企业文化 ， 支持动态的、严格的、科学的实验 。 通过主动地承担风险 ， 不但能从成功中学习 ， 也能从失败中学习 。 帮助团队快速并自动适应不断变化的环境 ， 进而帮助企业在市场竞争中脱颖而出 。

文章图片

2、关于价值流的三个关键要素 来自《DevOps实践指南》的关于价值流的三个关键要素：

• 前置时间（Lead Time ， 简称 LT）

前置时间在 DevOps 中是一项非常重要的指标 。 具体来说 ， 它是指一个需求从提出（典型的就是创建一个需求任务）的时间点开始 ， 一直到最终上线交付给用户为止的时间周期 。 这部分时间直接体现了软件开发团队的交付速率 ， 并且可以用来计算交付吞吐量 。 DevOps 的核心使命之一就是优化这段时长 。

• 增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time ， 简称 VAT/NVAT）

在精益思想中 ， 最重要的就是消除浪费 ， 也就是说最大化流程中那些增值活动的时长 ， 降低不增值活动的时长 。 在软件开发行业中 ， 典型的不增值活动有很多 ， 比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等 。

• 完成度和准确度（% Complete/Accurate ， 简称 %C/A）

这个指标用来表明工作的质量 ， 也就是有多少工作因为质量不符合要求而被下游打回 。 这里面蕴含了大量的沟通和返工成本 ， 从精益的视角来看 ， 也是一种浪费 。

文章图片

3、梳理企业内部的交付价值流

• 企业内部价值流程梳理会议

对于大型企业而言 ， 开展企业内部价值流梳理会议时 ， 可以选择处于改进中的项目里某个核心的业务模块 ， 同时参加会议的人员需要覆盖软件交付的所有环节 。 而且 ， 参会人员要尽量是相对资深的 ， 因为他们对自身所负责的业务和上下游都有比较深刻的理解 ， 比较容易识别出问题背后的根本原因 。