A:“能麻烦您给我讲一讲你们的工作流程吗?” B:“哦,这个呀,就是需求分析、设计、开发、测试、上线呗!” A:“Hum…” B:(心里不爽:明知故问嘛!) B:“你不是来给我们解决技术问题的嘛?你了解这些东西对我们有什么用?” A:“哦,但凡能用技术解决的问题都不是什么问题……不知道您听说过这句话吗?” (陷入尴尬)
这是个我曾经在做各种调研时,为了了解对方的端到端工作流程而习惯问的问题,当然收到的回答也是如上面一样相当的一致。
后来,我逐渐发现这种问问题的方法是基本上难以收获我想要的满意答案的,尤其是在同一个团队中不同的人使用的词汇和对流程理解不一致的情况下,但是从实际来说,这种认知不一致恰恰就是最普遍甚至可以说是几乎100%存在的情况。
而在 DevOps 转型的开始和过程中,从全局视角出发,持续跟踪和关注端到端流程(有时候两端可能还会延伸到当前团队的范围之外)中的瓶颈是 DevOps 非常重要的一个基本要求和能力,正所谓:
全局优化高于局部优化。 将局部经验转化为全局改进。
(这两句是我拼在一起的,他们有非常强烈的联系并持续相互作用,是一个持续改进的过程。)
在遇到 DevOps 之前,我遇到了“精益思想”,从中学会了“价值流”这样一个重要的视角和工具,所以从那时起就开始习惯从价值流的角度出发去思考和分析,逐渐觉得自己的视角开始不一样了,会不自觉的从全局优化的角度思考问题和寻找瓶颈。
庆幸的是,“精益思想”恰恰就是 DevOps 的重要思想基础之一,让我们回顾一下 DevOps 的“三步工作法”:
第一步:实现开发到运维工作快速地从左向右流动; 第二步:在从右向左的每个阶段中,应用持续、快速的工作反馈机制; 第三步:建立具有创意和高度信任的企业文化,支持动态的、严格的科学实验;
其中第一步的“……从左向右……”,和第二步的“……从右向左……”就是相对于价值流流动的方向来说的,所以“价值流”也是 DevOps 重要的思考工具和可视化工具。
如果能够利用好价值流这个工具,则能够使我们快速的统一团队语言和认知,并发现潜在的瓶颈点。
接下来,我便从精益思想的基础概念、精益思想在软件行业中的特点以及我在日常工作中的实践三个部分,来说一说“价值流”在 DevOps 转型工作中的重要作用。
精益思想来源于以“丰田生产方式”为代表的传统制造行业,在过去的几十年中已经被大量引入并被各行各业所实践。
“精益(Lean)”所针对并致力于消除的反义词是“浪费(Muda)”,至于为啥浪费的英文是是Muda?正是因为来源于“丰田生产方式”,用的是日语的音译。
什么是“浪费”?在《精益思想》一书中给出了如下定义:
浪费(Muda),专指消耗了资源而不创造价值的一切人类活动。
比如[1]:
那什么又是“价值(Value)”呢?简单来说就是:
那些对最终客户有积极意义和有用处的东西。
而精益思想的核心目标则是:
通过及时的反馈消除或将浪费转化为价值。
为了实现这个目标,精益思想总结归纳了5个基本的步骤或者说是原则[1]:
以上用粗体标注的文字都是非常重要基础概念,但由于篇幅有限并且本文重点不是给大家讲精益思想,而是希望把注意力放在价值流图对于开展 DevOps 转型工作的作用上,所以不再进一步解释,大家可以通过阅读《精益思想》这本书去进行系统性的了解。
说了那么一大堆,现在终于该说什么是价值流了……咳咳……
价值流是指从原材料转变为成品、并给它赋予价值的全部活动。
通常,我们用“价值流图”来对价值流进行可视化。
以可口可乐公司生产罐装的可口可乐为例,对于一提盒罐装可乐来说,粗略的价值流图大概长这样[1]:
生产一提盒罐装可乐的价值流
(虚线部分展示的是罐体回收并重新创造价值的过程。)
为什么说是“粗略”呢?是因为其中的每一个步骤都如同电子地图可以缩放,都有其内部的价值流动过程,所以“缩放”的思维在对待价值流这件事儿上非常重要,你必须知道在不同的场合下,需要关注的工作的粒度是怎样一个大小。
另外一个方面需要注意的是,价值流的每一个步骤都是有输入物和产出物的,换句话说:如果没有原料,你不可能凭空生产出任何东西。(其实就是管道思维)
那什么时候这些可乐才会真正的交付价值呢?其实就是在最后时刻——被最终客户(消费者)买回家喝进肚子里的时候。在那之前,这些可乐都处于“创造价值(增值)”或“产生浪费”的阶段。换句话说:
未被喝掉的可乐是没有价值的。
精益思想诞生于传统的生产制造行业,价值流图在展现传统生产制造行业的价值流动时是非常醒目和易于识别浪费的(精益思想在软件行业的落地最有名的就是“看板方法”,篇幅所限,就不在此介绍了,感兴趣的可以阅读《看板方法》一书)。
但是,在我们所处的IT行业,尤其是软件开发工作,与传统生产制造行业有相当大的区别,在我看来主要有以下不同:
软件交付的价值流,一般是从获得需求开始,到成功上线结束。如果要用价值流来表达一个较为常见的粗粒度的软件开发过程,大概是这样:
粗粒度的软件开发价值流
我想你应该会说:“这不就是瀑布式的流程吗?这有什么好画的?”
别急嘛!我就是简单表示一下,还记得我之前所说的“缩放”吧?来让我们展示个细粒度的价值流图——以我所就职的 ThoughtWorks 的交付实践为例,一个迭代中的价值流是这样的(只展现了Happy Path的情况,因为任何测试检查环节只要不通过,就会回退到开始开发的阶段):
ThoughtWorks 的软件交付实践价值流
哇咔咔!怎么样?是不是很多步骤?这还不是最细呢!
你可能会问:“步骤这么多?不累吗?交付速度能快吗?”
放心,不累,也很快,因为这一切都建立在自动化的基础之上。
而这些自动化的基础设施又是怎么来的呢?
正是由这张图上所看不见,但是其实处处都在的幕后工作者——Ops(运维工程师)所构建的。
在DevOps的世界里,运维工程师从项目的一开始就进入,并与其他角色紧密协作:评估未来上线后的运维环境,制定相应的对策和计划,搭建能够让其他角色快速开展工作的基础设施,并在整个开发过程中从运维侧解决阻碍价值快速流动的瓶颈。
这就是与过去传统的开发与运维相分离的工作方式本质上的不同。
说了这么多,这东西在做 DevOps 转型的时候怎么用啊?
我觉得主要体现在两个方面:
后者在看板方法中有更多的描述,所以这里我主要讲一讲前者。
最近在帮助客户开展DevOps转型工作的时候,需要同时应对5个试点团队,如何能够在一开始快速了解5个试点团队的现状,并且尽可能减少因为沟通中目标角色单一所造成的信息收集不全面的挑战呢?
答案就是:开展价值流分析工作坊。(经实践,2个小时就够,2个小时以上嘛……你能约出对方这么多时间吗?什么?能?那就做的更细致一些喽!)
工作坊的流程如下(这是我个人设计和在实践中完善的,不代表其他同仁的做法):
价值流分析工作坊
在工作坊的过程中,作为组织者,应当针对大家所贴的内容多问如下问题以便澄清和统一大家的认知:
通过工作坊,经常能够发现一些普遍性的问题,比如:团队中各个角色对于当前的交付流程理解不一致,实际实践与所绘制的价值流中的表现不一致等等。
另外还会发现一些让人哭笑不得的做法,比如:
运维工程师在哪里?
上图是梳理出来的价值流,下图是运维工程师们贴出来的自己的很多工作,这些工作压根就没有出现在价值流图上(正如之前在介绍价值流的时候所说的,运维工程师们是幕后英雄,他们的工作实际上贯穿了整个价值流流动过程,为价值流的流动构建了基础设施和条件)。
当时,当大家梳理完价值流之后,其中一位员工很肯定地说:“这样整个工作就做完了,剩下就是运维了,也就没啥事儿了!”
话毕,几个运维工程师站在旁边沉默不语……眼中似乎有晶莹的东西在闪烁……
价值流是能够让我们进行全局观察和优化的重要工具,在进行DevOps转型的过程中必不可少,学会很容易,但是需要坚持、自觉和重复的使用。
同时,通过价值流分析工作坊,我发现当前对于绝大多数团队来说,制约DevOps落地的最关键问题无外乎:
这是这个行业老大难的问题,同时让我感到可悲的是,国内很多知名大厂和IT服务公司依旧如此,还有那些号称十几年工作经验的人们,也依旧如此。
注1:来自于《精益思想》中文版 ↩ ↩ ↩