版權(quán)聲明：本作品采用【知識共享署名-非商業(yè)性使用-禁止演繹 4.0 國際許可協(xié)議】進行許可。

A：“能麻煩您給我講一講你們的工作流程嗎？”

B：“哦，這個呀，就是需求分析、設(shè)計、開發(fā)、測試、上線唄！”

A：“Hum...”

B：（心里不爽：明知故問嘛?。?/p>

B：“你不是來給我們解決技術(shù)問題的嘛？你了解這些東西對我們有什么用？”

A：“哦，但凡能用技術(shù)解決的問題都不是什么問題……不知道您聽說過這句話嗎？”

（陷入尷尬）

這是個我曾經(jīng)在做各種調(diào)研時，為了了解對方的端到端工作流程而習(xí)慣問的問題，當(dāng)然收到的回答也是如上面一樣相當(dāng)?shù)囊恢隆?/p>

后來，我逐漸發(fā)現(xiàn)這種問問題的方法是基本上難以收獲我想要的滿意答案的，尤其是在同一個團隊中不同的人使用的詞匯和對流程理解不一致的情況下，但是從實際來說，這種認知不一致恰恰就是最普遍甚至可以說是幾乎100%存在的情況。

而在DevOps轉(zhuǎn)型的開始和過程中，從全局視角出發(fā)，持續(xù)跟蹤和關(guān)注端到端流程（有時候兩端可能還會延伸到當(dāng)前團隊的范圍之外）中的瓶頸是DevOps非常重要的一個基本要求和能力，正所謂：

• 全局優(yōu)化高于局部優(yōu)化。
• 將局部經(jīng)驗轉(zhuǎn)化為全局改進。

（這兩句是我拼在一起的，他們有非常強烈的聯(lián)系并持續(xù)相互作用，是一個持續(xù)改進的過程。）

在遇到DevOps之前，我遇到了“精益思想”，從中學(xué)會了“價值流”這樣一個重要的視角和工具，所以從那時起就開始習(xí)慣從價值流的角度出發(fā)去思考和分析，逐漸覺得自己的視角開始不一樣了，會不自覺的從全局優(yōu)化的角度思考問題和尋找瓶頸。

慶幸的是，“精益思想”恰恰就是DevOps的重要思想基礎(chǔ)之一，讓我們回顧一下DevOps的“三步工作法”：

第一步：實現(xiàn)開發(fā)到運維工作快速地從左向右流動；

第二步：在從右向左的每個階段中，應(yīng)用持續(xù)、快速的工作反饋機制；

第三步：建立具有創(chuàng)意和高度信任的企業(yè)文化，支持動態(tài)的、嚴格的科學(xué)實驗；

其中第一步的“……從左向右……”，和第二步的“……從右向左……”就是相對于價值流流動的方向來說的，所以“價值流”也是DevOps重要的思考工具和可視化工具。

如果能夠利用好價值流這個工具，則能夠使我們快速的統(tǒng)一團隊語言和認知，并發(fā)現(xiàn)潛在的瓶頸點。

接下來，我便從精益思想的基礎(chǔ)概念、精益思想在軟件行業(yè)中的特點以及我在日常工作中的實踐三個部分，來說一說“價值流”在DevOps轉(zhuǎn)型工作中的重要作用。

什么是精益思想？

精益思想來源于以“豐田生產(chǎn)方式”為代表的傳統(tǒng)制造行業(yè)，在過去的幾十年中已經(jīng)被大量引入并被各行各業(yè)所實踐。

“精益（Lean）”所針對并致力于消除的反義詞是“浪費（Muda）”，至于為啥浪費的英文是是Muda？正是因為來源于“豐田生產(chǎn)方式”，用的是日語的音譯。

什么是“浪費”？在《精益思想》一書中給出了如下定義：

浪費（Muda），專指消耗了資源而不創(chuàng)造價值的一切人類活動。

比如^[1]：

• 需要糾正的錯誤。
• 生產(chǎn)了無需求的產(chǎn)品。
• 因生產(chǎn)了無需求的產(chǎn)品而造成的庫存和積壓。
• 不必要的工作。
• 員工的盲目走動。
• 貨物從一地到另一地的盲目搬運。
• 由于上道工序發(fā)送傳遞不及時，使下一道工序的人只能等待。
• 商品和服務(wù)不能滿足客戶的要求。

那什么又是“價值（Value）”呢？簡單來說就是：

那些對最終客戶有積極意義和有用處的東西。

而精益思想的核心目標(biāo)則是：

通過及時的反饋消除或?qū)⒗速M轉(zhuǎn)化為價值。

為了實現(xiàn)這個目標(biāo)，精益思想總結(jié)歸納了5個基本的步驟或者說是原則^[1]：

1. 定義價值；
2. 識別價值流，并消滅明顯的浪費步驟；
3. 并使保留下來的、創(chuàng)造價值的各個步驟重新流動起來；
4. 按客戶需要拉動價值；
5. 盡善盡美。

以上用粗體標(biāo)注的文字都是非常重要基礎(chǔ)概念，但由于篇幅有限并且本文重點不是給大家講精益思想，而是希望把注意力放在價值流圖對于開展DevOps轉(zhuǎn)型工作的作用上，所以不再進一步解釋，大家可以通過閱讀《精益思想》這本書去進行系統(tǒng)性的了解。

說了那么一大堆，現(xiàn)在終于該說什么是價值流了……咳咳……

價值流是指從原材料轉(zhuǎn)變?yōu)槌善?、并給它賦予價值的全部活動。

通常，我們用“價值流圖”來對價值流進行可視化。

價值流圖（Value Stream Map，簡稱VSM）

以可口可樂公司生產(chǎn)罐裝的可口可樂為例，對于一提盒罐裝可樂來說，粗略的價值流圖大概長這樣^[1]：

生產(chǎn)一提盒罐裝可樂的價值流

（虛線部分展示的是罐體回收并重新創(chuàng)造價值的過程。）

為什么說是“粗略”呢？是因為其中的每一個步驟都如同電子地圖可以縮放，都有其內(nèi)部的價值流動過程，所以“縮放”的思維在對待價值流這件事兒上非常重要，你必須知道在不同的場合下，需要關(guān)注的工作的粒度是怎樣一個大小。

另外一個方面需要注意的是，價值流的每一個步驟都是有輸入物和產(chǎn)出物的，換句話說：如果沒有原料，你不可能憑空生產(chǎn)出任何東西。（其實就是管道思維）

那什么時候這些可樂才會真正的交付價值呢？其實就是在最后時刻——被最終客戶（消費者）買回家喝進肚子里的時候。在那之前，這些可樂都處于“創(chuàng)造價值（增值）”或“產(chǎn)生浪費”的階段。換句話說：

未被喝掉的可樂是沒有價值的。

軟件開發(fā)過程中的價值流

精益思想誕生于傳統(tǒng)的生產(chǎn)制造行業(yè)，價值流圖在展現(xiàn)傳統(tǒng)生產(chǎn)制造行業(yè)的價值流動時是非常醒目和易于識別浪費的（精益思想在軟件行業(yè)的落地最有名的就是“看板方法”，篇幅所限，就不在此介紹了，感興趣的可以閱讀《看板方法》一書）。

但是，在我們所處的IT行業(yè)，尤其是軟件開發(fā)工作，與傳統(tǒng)生產(chǎn)制造行業(yè)有相當(dāng)大的區(qū)別，在我看來主要有以下不同：

• 軟件開發(fā)沒有“原料”，流入軟件開發(fā)價值流的是“需求”。
• 軟件開發(fā)是創(chuàng)造性的腦力工作，通過創(chuàng)新來產(chǎn)生價值，所以軟件開發(fā)及其易變，而制造業(yè)則具有低變異性。
• 軟件天然是“軟”的，相比“硬”的制造業(yè)來說，軟件更易于以低成本進行變化。
• 軟件交付的價值是：滿足最終客戶需要，并且可以工作的軟件。

軟件交付的價值流，一般是從獲得需求開始，到成功上線結(jié)束。如果要用價值流來表達一個較為常見的粗粒度的軟件開發(fā)過程，大概是這樣：

粗粒度的軟件開發(fā)價值流

我想你應(yīng)該會說：“這不就是瀑布式的流程嗎？這有什么好畫的？”

別急嘛！我就是簡單表示一下，還記得我之前所說的“縮放”吧？來讓我們展示個細粒度的價值流圖——以我所就職的ThoughtWorks的交付實踐為例，一個迭代中的價值流是這樣的（只展現(xiàn)了Happy Path的情況，因為任何測試檢查環(huán)節(jié)只要不通過，就會回退到開始開發(fā)的階段）：

ThoughtWorks的軟件交付實踐價值流

哇咔咔！怎么樣？是不是很多步驟？這還不是最細呢！

你可能會問：“步驟這么多？不累嗎？交付速度能快嗎？”

放心，不累，也很快，因為這一切都建立在自動化的基礎(chǔ)之上。

而這些自動化的基礎(chǔ)設(shè)施又是怎么來的呢？

正是由這張圖上所看不見，但是其實處處都在的幕后工作者——Ops（運維工程師）所構(gòu)建的。

在DevOps的世界里，運維工程師從項目的一開始就進入，并與其他角色緊密協(xié)作：評估未來上線后的運維環(huán)境，制定相應(yīng)的對策和計劃，搭建能夠讓其他角色快速開展工作的基礎(chǔ)設(shè)施，并在整個開發(fā)過程中從運維側(cè)解決阻礙價值快速流動的瓶頸。

這就是與過去傳統(tǒng)的開發(fā)與運維相分離的工作方式本質(zhì)上的不同。

價值流分析工作坊

說了這么多，這東西在做DevOps轉(zhuǎn)型的時候怎么用啊？

我覺得主要體現(xiàn)在兩個方面：

1. 在咨詢師剛剛接觸一個新團隊的時候，利用價值流去快速了解團隊現(xiàn)有的端到端交付現(xiàn)狀，統(tǒng)一團隊成員的認識；
2. 應(yīng)用看板方法，團隊定期進行價值流分析，不斷尋找新的瓶頸，從而“盡善盡美”，持續(xù)改進。

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

最近在幫助客戶開展DevOps轉(zhuǎn)型工作的時候，需要同時應(yīng)對5個試點團隊，如何能夠在一開始快速了解5個試點團隊的現(xiàn)狀，并且盡可能減少因為溝通中目標(biāo)角色單一所造成的信息收集不全面的挑戰(zhàn)呢？

答案就是：開展價值流分析工作坊。（經(jīng)實踐，2個小時就夠，2個小時以上嘛……你能約出對方這么多時間嗎？什么？能？那就做的更細致一些嘍?。?/p>

工作坊的流程如下（這是我個人設(shè)計和在實踐中完善的，不代表其他同仁的做法）：

1. 所有人做自我介紹。
2. 簡要介紹什么是價值流地圖及其作用。
3. 介紹產(chǎn)出物的要求（價值流圖、前置時間、實際完成時間），統(tǒng)一預(yù)期。
4. 每個角色使用便利貼按照時間順序書寫和排列自己的工作，相互不要進行交流，繪制時關(guān)注過程的輸入和輸出以及時間。
5. 所有人按照時間線從第一個人的價值流圖開始嘗試通過討論將全部工作串起來，并根據(jù)流動（關(guān)注輸入和輸出）進行分析。如果有缺失的就補上，如果有重復(fù)的就合并，如果有并行的就分開，如果有BAU工作而不會在流動中流經(jīng)的就去掉。
6. 歸類并劃分大的階段，比如需求分析、開發(fā)、測試、部署、發(fā)布等等。
7. 對每一個大的階段進行時間估算，最終推出前置時間和實際完成時間，嘗試大致分析核心瓶頸的位置。
8. 討論答疑，產(chǎn)出下一步的Action。

價值流分析工作坊

在工作坊的過程中，作為組織者，應(yīng)當(dāng)針對大家所貼的內(nèi)容多問如下問題以便澄清和統(tǒng)一大家的認知：

• 這是什么？能舉個例子描述一下場景嗎？
• 所依賴的輸入是什么？
• 這一步的輸出是什么？
• 多長時間會發(fā)生一次？
• 一次大概需要多長時間？
• 有什么遺漏的嗎？
• ……

通過工作坊，經(jīng)常能夠發(fā)現(xiàn)一些普遍性的問題，比如：團隊中各個角色對于當(dāng)前的交付流程理解不一致，實際實踐與所繪制的價值流中的表現(xiàn)不一致等等。

另外還會發(fā)現(xiàn)一些讓人哭笑不得的做法，比如：

• 因為畏懼合并代碼出問題，所以雖然有使用版本控制，但是在測試的時候是使用開發(fā)人員修改后的本地代碼進行打包，然后用FTP拷到測試環(huán)境進行手動測試，測試完成后才敢把本地的代碼變更提交進代碼庫。（測試時所使用的代碼和部署生產(chǎn)所使用的代碼壓根不是同一個代碼）
• 使用了版本控制，但是測試環(huán)境和生產(chǎn)環(huán)境的代碼不是從代碼倉庫拉取的，而是通過參照一份詳細羅列了修改過的文件的Word文檔，然后手工把這些修改過的文件通過FTP拷貝到不同環(huán)境的。（如果是這樣的話，那我們使用版本控制的目的到底是什么呢？僅僅是不需要使用QQ傳嗎？）

這里有兩張照片，也很有意思：

運維工程師在哪里？

上圖是梳理出來的價值流，下圖是運維工程師們貼出來的自己的很多工作，這些工作壓根就沒有出現(xiàn)在價值流圖上（正如之前在介紹價值流的時候所說的，運維工程師們是幕后英雄，他們的工作實際上貫穿了整個價值流流動過程，為價值流的流動構(gòu)建了基礎(chǔ)設(shè)施和條件）。

當(dāng)時，當(dāng)大家梳理完價值流之后，其中一位員工很肯定地說：“這樣整個工作就做完了，剩下就是運維了，也就沒啥事兒了！”

話畢，幾個運維工程師站在旁邊沉默不語……眼中似乎有晶瑩的東西在閃爍……

結(jié)語

價值流是能夠讓我們進行全局觀察和優(yōu)化的重要工具，在進行DevOps轉(zhuǎn)型的過程中必不可少，學(xué)會很容易，但是需要堅持、自覺和重復(fù)的使用。

同時，通過價值流分析工作坊，我發(fā)現(xiàn)當(dāng)前對于絕大多數(shù)團隊來說，制約DevOps落地的最關(guān)鍵問題無外乎：

1. 需求變更沒有節(jié)奏，需求實例化差；
2. 沒有自動化測試；
3. 人員能力弱，學(xué)習(xí)能力差。

這是這個行業(yè)老大難的問題，同時讓我感到可悲的是，國內(nèi)很多知名大廠和IT服務(wù)公司依舊如此，還有那些號稱十幾年工作經(jīng)驗的人們，也依舊如此。

學(xué)習(xí)，真的有那么難嗎？

1. 來自于《精益思想》中文版 ? ? ?