在
鳳凰專案這本書中一直提到卻沒有詳細說明的三步法(不知道翻三扳斧如何XD)，作者故意留到
DevOps Handbooks 這本書才詳細說明，這就是傳說中得埋梗。
第一步： 流程的原則 (the principle of flow)
所謂的流程談論的就是如何有效率的傳遞價值流程（ Value Stream）：也就是從 Business 端產生想法和需求，到 Customer 真正使用並且給予回饋（不論是金錢或是評價），所以第一部流程的原則就是減少 lead time，也就是減少從需求到部署商轉的時間。
書中整理出優化流程的步驟，也是我們每天努力改善的項目：
1. 把工作視覺化
2. Limit WIP
這兩個步驟應該不用多說，之前在
鳳凰項目沙盤推演 workshop 遊戲流程也有提到，想要深入瞭解可以參考"
看板實戰"。
3. 減少Batch Size (single piece flow)
4. 減少工作移交的數量
所謂Single Piece Flow 翻成白話文就減少批次處理的量，最好是一次做好一件事，只要做到這點就能減少工作移交的數量，越多工作移交的數量，就會需要更多的溝通和更多的文件。
5. 持續找出並鬆綁瓶頸
這也是鳳凰專案中不斷引用高德拉特博士的
移除瓶頸的聚焦五步驟：
1. 找出系統的制約因素
2. 決定如何利用系統的制約因素
3. 根據上述的決定，調整其他的一切
4. 把系統的制約因素鬆綁
5. 加入四打破了原有的制約因素，回到步驟一
既然第一步是要找出制約的因素，作者也幫忙列出 DevOps 常見的瓶頸產生處：
- 環境建立 (不管是開發和營運環境)
- 程式部署 (程式從git 拉下來到部署到Production 需要多少時間？)
- 測試建置與執行
- 過緊密的架構
消除價值流中得困難和浪費
除了瓶頸外，在整個價值流中處處都可能藏著浪費，等著我們找出來消滅：
- Particaly Done Work（開發過程中的半成品，甚至是等待review 的工作）
- Extra Processes（對於客戶與開發沒價值的SOP/文件/簽核）
- Extra Features（傳說中得 Over Design和 Gold plating）
- Task Switching（萬惡的Content Switch)
- Waiting（等待指示或簽核，等待資訊，等待誰同意....)
- Motion/ Handoffs （工作交流和換手的過程一些資訊很有可能跟著遺失或變質)
- Defects（不正確/遺失/不清楚的資訊和產品產生，從發現到解決拖的越長越浪費時間）
- Nonstandard or Manual work （工程師都知道重複做超過三次的東西都該自動化~XD）
- Heroics
最後一點 Heroics (action that is dramatic)特別值得拿出來講，書中舉的例子就是為了達成組織的某個(
恐怖的)目標，某些人或某些team 必須承受一些不合理的行動，而這些動作甚至會變成他們每天的工作，每次半夜兩點部署新的程式到Production ，都會產生一堆新的ticket 要處理（那變少測試，那邊要微調，那邊忘了升級，那邊配合人員沒通知....）
結論
瓶頸和浪費不會消失，但是希望可以透過視覺化的方式加速發現的過程，並且透過系統化的方式減少甚至消滅這些浪費。這時候就要透過第二步 Feedback 來幫忙。
謎之音
要注意！上面輕描帶寫的列出許多要改進的地方，要注意的事項，但是隨便一項就可以做到死，要怎麼從Day1 就把這些概念Build in 在日常的開發中就是硬實力，不是靠嘴巴講出來的，是要靠做出來的。這也是為什麼直到Docker出現後，DevOps 的議題才如烈火燎原般燒開，他從根本解決了許多瓶頸，有興趣可以參考這篇文章：
Docker and the Three Ways of DevOps Part 1: The First Way – Systems Thinking
