使用價值流圖來評定流程效率
當您建立建立「價值流程圖」(或 VSM)，其可協助您分析目前發行週期的流程。 VSM 旨在以視覺方式顯示小組在流程中創造價值的部分，以及產生浪費的部分。 目標是實現可為客戶提供最大價值，同時產生最少浪費的流程。 VSM 可協助您找出未提供任何價值，甚至會減少產品價值的領域。
讓我們看看 Tailspin 如何完成任務。
小組中的新進人員 Mara 想要建立 VSM，以協助了解現有流程。 藉由 VSM，Mara 將能了解小組在 DevOps 成熟度模型中適合的位置。 事實證明，與不成熟的小組相比，更成熟的小組通常能夠更快地發行更有把握且 Bug 更少的產品。
Mara 知道她尚未了解所有內容，因此她即將在會議室的白板上建立快速 VSM。 雖然可能還有一些隔閡和無解的問題，不過沒關係。 這只是開始。 當 Mara 盡其所能地完成工作後，她就能與小組分享。 VSM 會為每個人提供一個共同起點，為改善 Tailspin 開發和發行其網站的方法奠定第一步。
讓我們來看一下 Mara 的價值流圖。
了解目前的流程
Mara 在會議室召集小組，以便展示她的 VSM。
Mara：VSM 可以協助我們評估流程在哪些方面對客戶具有價值；在哪些方面消耗時間卻沒有產生任何價值。 我們的地圖從左上方的軟體功能規格開始。 讓我們只關注一項功能，以便了解該功能在目前發行週期中的運作狀況。
有些人翻了翻白眼，但 Mara 繼續解釋。
開發流程
想要建立新功能，目前需從在原始檔控制中建立標籤開始
。 小組中有一個人可以建立標籤，就是 Andy。 我們會透過電子郵件來要求標籤。 由於我們使用集中式版本控制系統，因此 Andy 必須等到所有現有程式碼都簽入並穩定之後，才能建立標籤。 在 Andy 建立標籤之後，我們會收到一封電子郵件，告知我們可以開始工作了。 這個流程最多會花費三天的時間，且對於客戶而言沒有任何價值。 對於客戶而言沒有任何價值的工作，應該盡可能花最少的時間處理。
在我們拿到所有必需檔案後，每位人員為功能撰寫程式碼大約需要花費四天
。 我們必須連上公司網路，才能存取原始檔控制。 這段時間對於客戶而言十分寶貴。 客戶想要這項功能。
測試流程
在決定具有穩定的組建之後，我們會更新試算表，告訴 Amita 有可供測試的組建，以及組建的位置
。 Amita 在兩天後才會收到通知。
Amita 會手動測試組建
。 這個流程會隨著程式碼基底的成長而變得更加冗長。 目前，讓我們假設為三天。 然後，Amita 會將 Bug 報告隨附於電子郵件寄給 Andy。 測試並不會創造價值，但卻是必要工作。
接著，Andy 必須花時間將 Bug 分級並指派工作。 Andy 可能需要花費額外三天來了解問題，並將問題指派給適當的開發人員。
作業程序
當 Amita 核准組建後，會將組建交接給 Tim。 Tim 必須將此組建部署至生產階段前伺服器，以進行更多測試。 生產階段前伺服器與執行網站所需的最新修補檔和更新通常不會同步。 Tim 大約需要兩天的時間，才能完成生產階段前部署並執行某些測試。 同樣地，雖然完成生產階段前部署並無法創造價值，但也是必要工作
。
當組建準備好投入生產環境之後，領導階層需要先核准發行，才能予以部署。 核准會在會議中發生。 領導階層針對該次發行，需要經過四天的會議與檢閱。
最後，Tim 會部署此功能，並將該功能提供給客戶，也就是 VSM 的右上方。 如果生產伺服器設定發生漂移，而無法與生產階段前環境同步，Tim 就需要先進行更新，而這又需要一天的時間 
。
計算客戶價值指標
現在，我們可以看看主要效態指標，並了解我們如何符合標準。
「整體前置時間」是指向客戶提供功能所需的時間。 在這個案例中，總花費時間為 22 天。 「流程時間」是指在可為客戶提供價值的功能上所花費時間。 在這個案例中，流程時間包含四天的程式碼撰寫，加上一天用於部署功能，總共五天。
「活動比率」即為流程時間除以整體前置時間：
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
這就是我們的效率。 將效率乘以 100 可得到百分比。 其結果會大於 0%，且通常小於 100%。 百分比越高表示效率越好。
換成我們的數字後如下所示：
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
將結果乘以 100，會得到 23%。
如您所見，我們還有許多可以改善的空間。 開發一項功能須花費 22 天實在過於耗時。
Tim：那麼這對我們有什麼幫助？
我們的目標是什麼？
Mara：這可以協助小組了解目前的處境，並找出產生浪費的領域。 我們想要將無法為客戶創造價值的時間降到最低。 我相信透過採用 DevOps 方法，我們可以確實改善效率。 一方面，我們可以將許多步驟自動化，這肯定能減少時間。
我並不是建議放棄我們的現有流程，但我認為可以一步步地朝向更有效率的流程邁進，且無須破壞我們的現有流程。
讓我們看看幾個可以改善的領域。
Andy：或許我們也可以從頭開始。 我需要花很長的時間才能為程式碼加上標籤，以便我們啟動新功能。 我必須四處奔走，請開發人員檢查他們擁有哪些內容，我們才能進行建置和測試。 如果您有辦法提升這項流程的效率，那麼我很樂意聽聽看。
另外，我還注意到上面沒有列出組建本身所需要的時間。 這項工作現在需要半天。 如果能把時間縮短那就太好了。
Amita：開發人員也不一定會更新試算表，讓我知道有新的組建需要進行測試。 如果有什麼方式可以確實執行這項工作，就可以節省很多時間。
Mara：太棒了！ 我覺得 DevOps 可以幫助我們解決所有問題。
Andy：我們現在沒有時間變更流程。 您聽到 Irwin 說的了。 我們現在深陷危機！
Mara：我了解。 我們現在先繼續做我們熟悉的工作。 但是，我們可以在流程中思考自己負責的部分，以及能夠如何改善。 我們可以在執行目前流程的同時做些小規模的改變。 然後，我們可以看看 DevOps 是否能夠協助我們，而無須破壞我們的流程。 我會保留這張圖表與效態計量。 如果我們最終採用 Azure DevOps 做法，我們就可以回顧這些數字。 或許我們可以在某個時間點更新 VSM。