【VSM每周观点】狭义的DevOps是一种局部优化 ｜第1期

如下图所示，我们对DevOps的理解通常分为 狭义DevOps和 广义DevOps。

狭义DevOps：一般只涉及科技（IT）的开发（Development）和运维（Operations）团队，涉及从 “需求分析、开发、测试、上线投产和运维”的研发运维过程的优化，专注于软件的快速交付；

广义DevOps（即BizDevOps）：要求业务和科技团队的高度融合协作，涉及从 “想法、价值定义、解决方案、需求分析、开发、测试、投产和运营”的端到端价值交付周期，专注于价值的快速实现。

从2009年提出 DevOps 至今已经有13年了，通过 DevOps 思想、方法和实践，促进开发和运维团队之间更好地协作，建设 DevOps/CICD 流水线，从而提升软件交付效率和缩短软件交付周期。DevOps运动对研发效能的提升是毋庸置疑的。

然而，狭义的 DevOps 只是业务价值端到端交付过程中的一个局部环节，根据约束理论（TOC），对局部环节的优化不一定会带来整体价值效能的提升，除非这个局部环节是整体价值交付过程的瓶颈。

如下图所示，狭义的DevOps和CICD流水线更聚焦于研发过程的自动化（也就是从代码提交到部署上线过程的自动化），当然狭义DevOps过程一般还包括需求分析、设计和编码阶段。

在用户提出想法开始，到最终将价值交付给用户，并获得收入的整个价值实现过程中，狭义的DevOps只是其中的一个局部环节。

当这个局部环节不是整体价值流的瓶颈时，继续对局部环节的过度优化对整体价值实现时间（最终用户能感知到的价值实现周期）不一定会产生效果，或是说产生的效果是微乎其微的。

我们再看下图的例子，在整个价值交付过程中，我们可以看到从商业案例到开发Backlog花费了6个月的时间，从编码完成到发布上线又花费了6个月的时间。

也就是说，在端到端价值交付过程中，更大的瓶颈在于价值交付过程的前期阶段（构建商业案例、等待案例审批等）和后期阶段（等待测试、等待上线），而不是在开发编码阶段。

在这种情况下，我们需要将优化的关注点放在价值交付过程的前期阶段（构建商业案例、等待案例审批等）和后期阶段（等待测试、等待上线），而不是在开发编码阶段。

由于当前开发编码阶段不是端到端价值交付过程中的瓶颈，如果我们还是将更多的人员和资源用于开发编码时，将会出现什么情况呢？

显而易见，端到端的价值交付周期不会有明显的缩短，同时这样还会产生大量已开发完成但是排队等待测试和上线的“半成品”，而这些“半成品”是无法交付给用户的，也就意味着无法产生价值和实现企业营收的。

因此，识别价值交付端到端过程的瓶颈，并针对当前最大的瓶颈进行优化，才能最大化缩短端到端的价值交付周期，从而提升用户体验和加快价值实现。

最简单也是最具成效的方法是，我们可以采用价值流映射（Value Stream Mapping）实践，花费2-4小时的时间与价值交付过程的每个角色一起绘制价值流图（Value Stream Map）。

价值流图的绘制要尽可能涉及价值交付的全过程（涵盖业务和IT），同时要求每个过程步骤的角色（每个角色可以只派1-2名代表）都参与进来。如下是价值流图绘制的例子：

• 建立价值流动的全局视角，有助于各个职能团队建立以客户为中心的系统思维；
• 直观的看到每个环节的事实数据，而不是依托员工的经验主义
• 识别当前最大的瓶颈，将精力聚焦于当前瓶颈的优化上。如上图数据显示67%（即32天）的时间花费在流程等待中。由此可见，我们应当把优化的重点放在流程优化，而不是局部的资源效率提升上。