版权声明：本作品采用【知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议】进行许可。

A：“能麻烦您给我讲一讲你们的工作流程吗？”

B：“哦，这个呀，就是需求分析、设计、开发、测试、上线呗！”

A：“Hum...”

B：（心里不爽：明知故问嘛！）

B：“你不是来给我们解决技术问题的嘛？你了解这些东西对我们有什么用？”

A：“哦，但凡能用技术解决的问题都不是什么问题……不知道您听说过这句话吗？”

（陷入尴尬）

这是个我曾经在做各种调研时，为了了解对方的端到端工作流程而习惯问的问题，当然收到的回答也是如上面一样相当的一致。

后来，我逐渐发现这种问问题的方法是基本上难以收获我想要的满意答案的，尤其是在同一个团队中不同的人使用的词汇和对流程理解不一致的情况下，但是从实际来说，这种认知不一致恰恰就是最普遍甚至可以说是几乎100%存在的情况。

而在DevOps转型的开始和过程中，从全局视角出发，持续跟踪和关注端到端流程（有时候两端可能还会延伸到当前团队的范围之外）中的瓶颈是DevOps非常重要的一个基本要求和能力，正所谓：

• 全局优化高于局部优化。
• 将局部经验转化为全局改进。

（这两句是我拼在一起的，他们有非常强烈的联系并持续相互作用，是一个持续改进的过程。）

在遇到DevOps之前，我遇到了“精益思想”，从中学会了“价值流”这样一个重要的视角和工具，所以从那时起就开始习惯从价值流的角度出发去思考和分析，逐渐觉得自己的视角开始不一样了，会不自觉的从全局优化的角度思考问题和寻找瓶颈。

庆幸的是，“精益思想”恰恰就是DevOps的重要思想基础之一，让我们回顾一下DevOps的“三步工作法”：

第一步：实现开发到运维工作快速地从左向右流动；

第二步：在从右向左的每个阶段中，应用持续、快速的工作反馈机制；

第三步：建立具有创意和高度信任的企业文化，支持动态的、严格的科学实验；

其中第一步的“……从左向右……”，和第二步的“……从右向左……”就是相对于价值流流动的方向来说的，所以“价值流”也是DevOps重要的思考工具和可视化工具。

如果能够利用好价值流这个工具，则能够使我们快速的统一团队语言和认知，并发现潜在的瓶颈点。

接下来，我便从精益思想的基础概念、精益思想在软件行业中的特点以及我在日常工作中的实践三个部分，来说一说“价值流”在DevOps转型工作中的重要作用。

什么是精益思想？

精益思想来源于以“丰田生产方式”为代表的传统制造行业，在过去的几十年中已经被大量引入并被各行各业所实践。

“精益（Lean）”所针对并致力于消除的反义词是“浪费（Muda）”，至于为啥浪费的英文是是Muda？正是因为来源于“丰田生产方式”，用的是日语的音译。

什么是“浪费”？在《精益思想》一书中给出了如下定义：

浪费（Muda），专指消耗了资源而不创造价值的一切人类活动。

比如^[1]：

• 需要纠正的错误。
• 生产了无需求的产品。
• 因生产了无需求的产品而造成的库存和积压。
• 不必要的工作。
• 员工的盲目走动。
• 货物从一地到另一地的盲目搬运。
• 由于上道工序发送传递不及时，使下一道工序的人只能等待。
• 商品和服务不能满足客户的要求。

那什么又是“价值（Value）”呢？简单来说就是：

那些对最终客户有积极意义和有用处的东西。

而精益思想的核心目标则是：

通过及时的反馈消除或将浪费转化为价值。

为了实现这个目标，精益思想总结归纳了5个基本的步骤或者说是原则^[1]：

1. 定义价值；
2. 识别价值流，并消灭明显的浪费步骤；
3. 并使保留下来的、创造价值的各个步骤重新流动起来；
4. 按客户需要拉动价值；
5. 尽善尽美。

以上用粗体标注的文字都是非常重要基础概念，但由于篇幅有限并且本文重点不是给大家讲精益思想，而是希望把注意力放在价值流图对于开展DevOps转型工作的作用上，所以不再进一步解释，大家可以通过阅读《精益思想》这本书去进行系统性的了解。

说了那么一大堆，现在终于该说什么是价值流了……咳咳……

价值流是指从原材料转变为成品、并给它赋予价值的全部活动。

通常，我们用“价值流图”来对价值流进行可视化。

价值流图（Value Stream Map，简称VSM）

以可口可乐公司生产罐装的可口可乐为例，对于一提盒罐装可乐来说，粗略的价值流图大概长这样^[1]：

生产一提盒罐装可乐的价值流

（虚线部分展示的是罐体回收并重新创造价值的过程。）

为什么说是“粗略”呢？是因为其中的每一个步骤都如同电子地图可以缩放，都有其内部的价值流动过程，所以“缩放”的思维在对待价值流这件事儿上非常重要，你必须知道在不同的场合下，需要关注的工作的粒度是怎样一个大小。

另外一个方面需要注意的是，价值流的每一个步骤都是有输入物和产出物的，换句话说：如果没有原料，你不可能凭空生产出任何东西。（其实就是管道思维）

那什么时候这些可乐才会真正的交付价值呢？其实就是在最后时刻——被最终客户（消费者）买回家喝进肚子里的时候。在那之前，这些可乐都处于“创造价值（增值）”或“产生浪费”的阶段。换句话说：

未被喝掉的可乐是没有价值的。

软件开发过程中的价值流

精益思想诞生于传统的生产制造行业，价值流图在展现传统生产制造行业的价值流动时是非常醒目和易于识别浪费的（精益思想在软件行业的落地最有名的就是“看板方法”，篇幅所限，就不在此介绍了，感兴趣的可以阅读《看板方法》一书）。

但是，在我们所处的IT行业，尤其是软件开发工作，与传统生产制造行业有相当大的区别，在我看来主要有以下不同：

• 软件开发没有“原料”，流入软件开发价值流的是“需求”。
• 软件开发是创造性的脑力工作，通过创新来产生价值，所以软件开发及其易变，而制造业则具有低变异性。
• 软件天然是“软”的，相比“硬”的制造业来说，软件更易于以低成本进行变化。
• 软件交付的价值是：满足最终客户需要，并且可以工作的软件。

软件交付的价值流，一般是从获得需求开始，到成功上线结束。如果要用价值流来表达一个较为常见的粗粒度的软件开发过程，大概是这样：

粗粒度的软件开发价值流

我想你应该会说：“这不就是瀑布式的流程吗？这有什么好画的？”

别急嘛！我就是简单表示一下，还记得我之前所说的“缩放”吧？来让我们展示个细粒度的价值流图——以我所就职的ThoughtWorks的交付实践为例，一个迭代中的价值流是这样的（只展现了Happy Path的情况，因为任何测试检查环节只要不通过，就会回退到开始开发的阶段）：

ThoughtWorks的软件交付实践价值流

哇咔咔！怎么样？是不是很多步骤？这还不是最细呢！

你可能会问：“步骤这么多？不累吗？交付速度能快吗？”

放心，不累，也很快，因为这一切都建立在自动化的基础之上。

而这些自动化的基础设施又是怎么来的呢？

正是由这张图上所看不见，但是其实处处都在的幕后工作者——Ops（运维工程师）所构建的。

在DevOps的世界里，运维工程师从项目的一开始就进入，并与其他角色紧密协作：评估未来上线后的运维环境，制定相应的对策和计划，搭建能够让其他角色快速开展工作的基础设施，并在整个开发过程中从运维侧解决阻碍价值快速流动的瓶颈。

这就是与过去传统的开发与运维相分离的工作方式本质上的不同。

价值流分析工作坊

说了这么多，这东西在做DevOps转型的时候怎么用啊？

我觉得主要体现在两个方面：

1. 在咨询师刚刚接触一个新团队的时候，利用价值流去快速了解团队现有的端到端交付现状，统一团队成员的认识；
2. 应用看板方法，团队定期进行价值流分析，不断寻找新的瓶颈，从而“尽善尽美”，持续改进。

后者在看板方法中有更多的描述，所以这里我主要讲一讲前者。

最近在帮助客户开展DevOps转型工作的时候，需要同时应对5个试点团队，如何能够在一开始快速了解5个试点团队的现状，并且尽可能减少因为沟通中目标角色单一所造成的信息收集不全面的挑战呢？

答案就是：开展价值流分析工作坊。（经实践，2个小时就够，2个小时以上嘛……你能约出对方这么多时间吗？什么？能？那就做的更细致一些喽！）

工作坊的流程如下（这是我个人设计和在实践中完善的，不代表其他同仁的做法）：

1. 所有人做自我介绍。
2. 简要介绍什么是价值流地图及其作用。
3. 介绍产出物的要求（价值流图、前置时间、实际完成时间），统一预期。
4. 每个角色使用便利贴按照时间顺序书写和排列自己的工作，相互不要进行交流，绘制时关注过程的输入和输出以及时间。
5. 所有人按照时间线从第一个人的价值流图开始尝试通过讨论将全部工作串起来，并根据流动（关注输入和输出）进行分析。如果有缺失的就补上，如果有重复的就合并，如果有并行的就分开，如果有BAU工作而不会在流动中流经的就去掉。
6. 归类并划分大的阶段，比如需求分析、开发、测试、部署、发布等等。
7. 对每一个大的阶段进行时间估算，最终推出前置时间和实际完成时间，尝试大致分析核心瓶颈的位置。
8. 讨论答疑，产出下一步的Action。

价值流分析工作坊

在工作坊的过程中，作为组织者，应当针对大家所贴的内容多问如下问题以便澄清和统一大家的认知：

• 这是什么？能举个例子描述一下场景吗？
• 所依赖的输入是什么？
• 这一步的输出是什么？
• 多长时间会发生一次？
• 一次大概需要多长时间？
• 有什么遗漏的吗？
• ……

通过工作坊，经常能够发现一些普遍性的问题，比如：团队中各个角色对于当前的交付流程理解不一致，实际实践与所绘制的价值流中的表现不一致等等。

另外还会发现一些让人哭笑不得的做法，比如：

• 因为畏惧合并代码出问题，所以虽然有使用版本控制，但是在测试的时候是使用开发人员修改后的本地代码进行打包，然后用FTP拷到测试环境进行手动测试，测试完成后才敢把本地的代码变更提交进代码库。（测试时所使用的代码和部署生产所使用的代码压根不是同一个代码）
• 使用了版本控制，但是测试环境和生产环境的代码不是从代码仓库拉取的，而是通过参照一份详细罗列了修改过的文件的Word文档，然后手工把这些修改过的文件通过FTP拷贝到不同环境的。（如果是这样的话，那我们使用版本控制的目的到底是什么呢？仅仅是不需要使用QQ传吗？）

这里有两张照片，也很有意思：

运维工程师在哪里？

上图是梳理出来的价值流，下图是运维工程师们贴出来的自己的很多工作，这些工作压根就没有出现在价值流图上（正如之前在介绍价值流的时候所说的，运维工程师们是幕后英雄，他们的工作实际上贯穿了整个价值流流动过程，为价值流的流动构建了基础设施和条件）。

当时，当大家梳理完价值流之后，其中一位员工很肯定地说：“这样整个工作就做完了，剩下就是运维了，也就没啥事儿了！”

话毕，几个运维工程师站在旁边沉默不语……眼中似乎有晶莹的东西在闪烁……

结语

价值流是能够让我们进行全局观察和优化的重要工具，在进行DevOps转型的过程中必不可少，学会很容易，但是需要坚持、自觉和重复的使用。

同时，通过价值流分析工作坊，我发现当前对于绝大多数团队来说，制约DevOps落地的最关键问题无外乎：

1. 需求变更没有节奏，需求实例化差；
2. 没有自动化测试；
3. 人员能力弱，学习能力差。

这是这个行业老大难的问题，同时让我感到可悲的是，国内很多知名大厂和IT服务公司依旧如此，还有那些号称十几年工作经验的人们，也依旧如此。

学习，真的有那么难吗？

1. 来自于《精益思想》中文版 ↩ ↩ ↩