什麼是價值流

傳統的工作中，不同的職位都只關注自己所交付的東西，比如產品經理關注產品需求檔案的交付，開發人員關注軟體程式碼的交付，運維人員關注於軟體產品的部署。

隨著DevOps與敏捷的發展，它們越來越強調交付整體價值，而不是單一角色的交付內容。

因此，價值流的意義就體現出來了。價值流是DevOps的關鍵概念之一。

根據《DevOps精要》的解釋，我們可以從創造價值以響應客戶請求的角度，來考慮一下組織中的工作。完成請求所需要實施的相關行動，可以按順序排列起來，這稱為價值流。

什麼是價值流圖

價值流圖就是視覺化的價值流。

它大概長下圖的樣子。

如何畫價值流圖

畫價值流圖其實很簡單：

1. 識別處理請求的關鍵步驟

2. 分析每個關鍵步驟所需的3個度量資料

   1. 前置時間 Lead Time，LT
   2. 處理時間 Process Time，PT
   3. 完成度與準確度百分比 the Percent Complete and Accurate，%C/A
3. 將這些步驟組織為一個創造預期結果的活動序列

價值流圖畫好之後，最有價值的資訊是流中每個步驟的3個度量資料，即前置時間(Lead Time，LT)、處理時間(Process Time，PT)及 完整度與準確度百分比(the Percent Complete and Accurate，%C/A)。

前置時間

前置時間是供應鏈管理中的一個術語，是指從採購方開始下單訂購到供應商交貨所間隔的時間。

對應到我們的軟體開發中，則是指一個任務從建立到完成的時間。如下圖所示。

處理時間

處理時間指的是一個任務從開始做到完成所需的時間。如下圖所示。

完整度與準確度百分比

一個任務完成了並不意味著它是準確的。

舉個很簡單的例子，我們讀書的時候寫作業，通常我們都能100%的完成，但並不能百分百的正確。

這在軟體開發中也非常常見，一個需求被實現了，但和最初的描述並不一致。

通過完整度與準確度百分比（%C/A）可以分析專案的返工成本。

畫價值流圖的幾個tips：

1. 不要過度細化關鍵步驟，大致可以按照看板上的列一一對應或略多。
2. 建議關鍵步驟數量不要超過15個。
3. 可以按有堆積或由於等待而產生延遲來畫每個步驟。
4. 實踐中，計算這些度量的數值是一個很大的挑戰。一個比較可行的做法是取每個迭代的幾張卡，然後計算PT的平均值。LT則看它從上一步挪動到下一步等待了多少天，也取平均值。%C/A則難免會拍腦袋得到數值了，這不可避免。
5. 某個關鍵會議也可以是步驟之一。比如釋出評審會。

真實案例分析價值流圖

下面這張價值流圖是來自我一個真實的案例。

對於這個圖上的資料我做一些說明：

• 不是所有公司的關鍵流程都長這個樣子，公司不同專案不同，畫出來的價值流圖也不同。
• 設計稽核的%C/A只有60%是因為當時這個專案的產品經理設計原型的時候並沒有頻繁和業務方溝通，導致設計的東西稽核的時候經常返工。
• 軟體開發的LT有12天那麼長，是因為很多卡ready了之後，需要等待排進某個迭代，所以平均等待時間有7天。這個數位在很多公司可能更長。
• 釋出申請和釋出上線的LT都挺長的，也是因為申請需要等待領導審批，釋出需要排期，所以等待時間也挺長。
• 使用者驗收測試的%C/A只有70%也是因為開發過程中並沒有頻繁獲取業務方的反饋，導致使用者驗收測試的時候發現挺多不符合預期的情況。

從上圖的資料中我們可以得到一些關鍵資訊：

1. PT/LT只有39.2%，這就意味著中間有大量的等待時間。那我們就可以具體分析每個等待時間該如何優化。
2. 構建上傳和測試環境部署這兩步都沒有等待時間，而且%C/A是100%。因為這個案例中它們都是利用pipeline自動化完成的。因此，自動化能幫助我們提高%C/A和縮短等待時間。
3. 平均%C/A是88.75%，意味著有可以改進的空間。那我們就可以具體分析每個步驟中為什麼達不到100%。
4. 經過分析我們發現，很多%C/A不能達到100%的原因是，這個步驟的人並沒有頻繁的向前一個步驟獲取反饋來驗證自己是否做對了。
5. 經過分析我們發現，很多LT長是因為，有一些審批流程必須等到領導稽核才能往下繼續走，而領導往往不能及時審批。還有一些LT長是因為沒有視覺化看板，不同步驟的人並不知道工作已經ready了。

在上面的例子中，花費在創造預期成果上的工作時間比例， 僅佔總開銷時間的39.2%。這樣的情況在常規IT部門中，類似的佔比數位相當普遍，甚至更低。

上面的例子根據價值流圖最終分析產出的報告有很多，這裡就不詳細展開說了。每個數位都可以研究背後的原因和找到改進的方案。

有了價值流圖之後，通常我們可以提出來這3個問題：

1. 為什麼這些工作步驟的%C/A值低於100%？我們如何才能夠完全杜絕錯誤從一個步驟
   被傳遞到下一個步驟（並因返工而浪費時間和資源）？
2. 除了開發產品的時間，具體有什麼因素導致了lead time？我們如何能夠大幅降低佇列和等
   待所損耗的時間？

3、我們如何改變工作實踐，來降低每個步驟的處理的時長？

值流圖的好處

1. 價值流圖的好處在於讓參與的團隊成員對整個流程有視覺化的資料化的認知。並清晰的知道該從哪個步驟入手開始改進。
2. 其次，過程的視覺化呈現，有助於聚焦到被創造的價值上，而不是被實施的動作上。員工們和經理們常常能很好地理解他/她們的日常任務（做什麼），而忽視了預期成果（為什麼）。
3. 再次，價值流圖有助於識別和消除瓶頸，並避免區域性優化的陷阱：即把時間和精力花費在根本沒有效果甚至帶來負面效果的約束消除上。
4. 最後，對價值流的瞭解，有助於實現DevOps的關鍵思想：構建一個順暢、一致經各個步驟的價值流，使得我們能夠持續地、有節奏地、沒有非必要的延遲、並以最優的資源使用方式來交付成果。

基於Eliyahu Goldratt提出的約束理論，任何系統中，在任何一個時間點上，有且僅有一個真正的瓶頸，這個瓶頸拖慢了工作，同時，花費在除了消除這個瓶 頸點之外的任何事情上的精力，都可以說是浪費。

總結

要畫出完整的價值流圖，一定要去研究專案中真實的實踐是什麼樣子的，不能憑空想象，也不要去指望某些記錄的檔案資訊，因為他們常常沒人維護。

價值流圖是幫助我們更好的構建DevOps的一種方式，要想做好DevOps只憑這一點是遠遠不夠的。

如果大家對相關話題感興趣，可以給我留言，我們一起討論更多可能性。

參考：《DevOps精要》