精益思想（Lean Thinking）在數字化轉型中一直扮演着重要的角色。精益源自20世紀50年代日本豐田發明的生産方法（TPS），即精益生産。基于這套方法論豐田實作了成本效益結合，大大提升了日本汽車的品質與成本優勢，使得世界汽車工業重心開始由美國向日本傾斜。
在上期DevOps系列直播中，我們為大家帶來了“精益與DevOps如何相得益彰”的主題分享，為大家詳細地分析了精益與DevOps的關系及實踐，本期直播我們邀請到DevOps解決方案架構師黃錦輝，帶來《精益思想在軟體傳遞中的應用》主題分享，深入挖掘解析精益思想的内涵，以及在軟體傳遞領域，精益如何實踐應用。
本次直播設有稽核，待稽核通過後即可觀看
Tips：如您不友善檢視回放，可閱讀以下總結文章，全文約4000字，預計閱讀時間7-9分鐘
為什麼需要精益？
在數字化轉型趨勢中，業務靈活（BVSSH）是核心目标，即更快（Sooner）、更安全（Safer）地傳遞更高品質（Better）的價值（Value）給到客戶，同時讓客戶和員工滿意（Happier）。
B-Better：
代表的是品質（Quality），例如更少的生産事故、更短的故障恢複時間（MTTR）和代碼品質等。品質必須是内建的，而不是事後再檢查。
S-Sooner：
更短的上線時間。即縮短前置時間（Lead Time）、提高吞吐量(Throughput)，提升流動效率(Flow Efficiency)。
S-Safer
滿足持續的合規性（Continuous Compliance），考慮性能要求(Agile not Fragile)。
H-Happier
客戶滿意和員工幸福。
DevOps和靈活開發這兩類軟體開發方法論已被企業廣泛采用，那為什麼還需要精益呢？其實盡管我們在軟體傳遞中已經應用DevOps和靈活實踐，但仍然會發現仍面臨着如下挑戰：
基本上沒有人能夠說清楚軟體傳遞全過程，例如從使用者提出需求開始，到最後将産品/服務傳遞給客戶，會經過哪些步驟和工具，資訊怎麼傳遞流動；
在研發過程中做了很多“優化”，軟體傳遞周期卻沒有明顯的縮短；
過度關注在人力方面，忽視了軟體傳遞過程，導緻内部資源使用率雖然有所提升，但整體軟體傳遞效率實際是有下降的，反而會降低軟體品質。
精益思想與核心原則
精益思想的前世今生
20世紀50年代，大野耐一在日本豐田發明了豐田生産系統 (TPS)，創立了高效益、低消耗的生産方式（後被MIT研究團隊稱為“精益生産”），經過多年的實踐使得日本的汽車工業趕超美國。當時精益更多是應用于制造業領域。1996年，書籍《LEAN THINKING》（《精益思想》）出版，這本書高度歸納了精益思想和原則，并将精益方式逐漸擴充到制造業以外的領域。随着2003年《精益軟體開發》的出版，精益思想真正開始應用于軟體領域中。
什麼是精益IT？
精益IT協會将精益IT定義為：“精益IT是精益制造和精益服務的原則的延伸，用于資訊技術産品和服務的開發和管理。其目标是不斷提高IT組織為客戶提供的價值以及IT人員的專業水準。”
精益IT專注于提高IT人員，IT流程和資訊技術，以便為客戶提供更多價值。精益的本質是一種思考和行動的方式。精益IT還提到了如下七個概念，其中“提升客戶價值”，是精益追求的目标；“減少浪費”是精益的核心，即通過不斷地去減少過程中的浪費，增加價值。
精益的五個關鍵原則
首先，要明确客戶價值，一切價值都是圍繞客戶展開的；
其次，基于客戶價值，建立以客戶為中心的價值流；
再次，建立快速的流動機制，消除過程的瓶頸和浪費；
然後，所有的價值流都是圍繞客戶進行的，是由客戶拉動，而不是生産後再推動給客戶;
最後，盡可能第一次就把事情做好，在每個階段保障品質，并通過可視化建立回報，持續改進。
精益的核心思想
基于以上五個原則，精益的核心思想包含如下5個方面：
核心1：定義客戶的價值-誰是我們的客戶
價值是由客戶定義，代表了客戶對于特定産品或者服務的需求。我們需要持續關注客戶價值，以及他們從産品或服務中感覺到的價值。
核心2：價值流思想-建立客戶視角的系統思維
價值流：
是由将産品或者服務從概念到傳遞給客戶的所有任務和活動組成，包含了所有的資訊、工作和物料流。
價值流圖（VSM）：
是精益制造或精益企業技術，用于記錄、分析和改進為客戶生産産品或服務所需的資訊流或物料流。價值流圖在下文“精益在軟體傳遞的應用”中，我們會詳細闡述。借助價值流圖，能幫助我們：
- 提供價值傳遞全周期的視圖；
- 建立客戶視角的系統思維；
- 提供驅動改進的定量資料。價值流會量化很多資料或者名額，可以驅動我們不斷持續地改善。
核心3：流動效率—優于資源效率
我們在整個軟體傳遞周期中，經常遇到整體傳遞效率沒有明顯提升的情況，即流動效率低的問題。如何實作端到端快速價值傳遞？這需要從以資源效率為核心，轉變為以流動效率為核心來組織軟體傳遞過程。
▲ 圖檔來源于書籍《This is Lean》
資源效率，是指從組織内部視角，審視各個獨立環節的産出效率，關注的是内部資源及職能。而流動效率是指從客戶的角度，審視客戶價值順暢流動的程度，關注的是客戶價值。
前置時間：即從使用者提出需求開始，到最終傳遞給客戶整體價值的端到端的時間。例如，上文舉例的醫院，前置時間為42天。如果去一站式的私人醫院檢查，醫生診斷快速，從初診到确診的檢查報告，排隊等待時間也大大縮短。因為一站式私人醫院關注的是流動效率。
過度局部優化資源效率，可能會帶來額外的工作，你在工作中不斷切換任務，導緻整體工作時間增加，使得下一個環節的人或者客戶經常處于等待狀态，流動效率低。
核心4：品質内建—盡早發現并解決問題
在豐田裡有個實踐“安燈拉繩”（Andon Cord）。在生産制造過程中，當一線員工發現其中的工序有異常，會拉動手邊的繩子-安燈拉繩，值班經理便會很快看見拉動繩子的員工是在幾号崗位、在工廠中的房間哪條流水線，這時會和專家一起檢查生産，群策群力。如在特定的時間段解決不了時，便會決定停止整條生産線的運作。
圖檔來源于網絡
安燈拉繩的做法，強調盡可能在問題出現的第一時間去發現并且解決。如暫時解決不了便會停下生産線，不把問題留着轉移到生産的下一個環節，這也是品質内建的展現。
品質内建，需要3個因素來展現：
建立信任的心理安全的環境
整條生産線停止運作的特殊情況，在絕大多數制造業工廠裡是很大的事故，而豐田給予信任、心理安全的環境，來保障品質内建的實踐。
可視化與透明性
整條生産流水線，以及安燈系統，都是通過可視化方式展示。
群策群力
需要團隊共同決策、一起解決問題。
核心5：持續改善—随時随地全員參與
改善，意味着持續改進，不斷否定現狀，尋求更高的水準。無論是在軟體傳遞過程，還是個人職業生涯，改善的套路提供了一種面對未知的思路，進而漸進式地不斷提升，持續進化。
需注意的是，改善并不是定期改善，而是随時随地全員參與。例如當軟體開發中發現可以改善的環節時，應立即去改善。
精益在軟體傳遞的應用
實踐1：價值流圖在軟體中的應用
第一層（最上層）為資訊流，即供應商和客戶之間的資訊流，中間會經過釋出管理過程。其中，資訊流的需求，企業内部會用到許多工具，比如需求管理工具，版本工具，自動化工具等。
第二層（中間層）為生産的過程流。例如軟體傳遞中，會經過需求分析設計、開發、測試、部署、釋出投産等流程階段。這裡會涉及幾個量化的名額-前置時間、周期時間、處理時間、安裝時間，我們在下文再一一詳細解釋。
第三層（最底層）是根據各個階段裡量化的名額，去繪制時間流水線。例如需求分析（第一個凹處水準線）花了0.5小時，等待開發（第二個凸處水準線）花了1天，開發（第三個凹處水準線）用了1.5小時，繼續等待（第四個凸處水準線）花了2天等等，以此類推，前置時間總共花了12.5天，處理時間為3.5天。
▲ VSM價值流圖（圖檔來源于網絡）
量化名額的概念：
前置時間（Lead Time）：
從使用者提出需求開始，到最終傳遞給客戶整體價值的端到端的時間。這是對客戶關鍵的時間，客戶隻關注整體花費的時間，期間的過程客戶并不在意。在如上價值流圖中，前置時間為12.5天
周期時間（Cycle Time）:
各個階段團隊處理的時間。例如需求分析花了0.5個小時，則周期時間為0.5個小時。
處理時間（Process Time）：
也稱流程時間，是周期時間的總和。圖中周期時間為0.5h+1.5h+1h+0.5h=3.5h，即對客戶來說，有價值的時間是3.5h，其餘等待的額外時間對于客戶來說是沒有價值的。
安裝時間（Setup Time）：
環境準備的時間。例如代碼開發需準備本地的開發環境，準備消耗了多長時間，即為安裝時間
還有一種價值流圖的延伸-流架構（Flow Framework），詳情可見PPT及直播回顧。
點選下載下傳PPT：内容中心
實踐2：消除浪費——區分3種活動類型
通過價值流把名額量化提煉出來後，我們下一步要做的是識别浪費，并進行改善。針對不同的活動類型，我們可以采取不同的方式。
消除非增值活動
非增值活動即完全不會帶來價值的活動，例如庫存、返工、等待等，這類活動需要直接消除。
最小化必要非增值
必要非增值，例如員工進行教育訓練技能是必要的，但對于客戶來說并不創造直接價值，這類活動需要最小化縮短時間。
優化增值活動
增值活動，例如軟體需求分析、代碼編寫等活動對于客戶是增值的，這類活動需要借助工具平台（例如DevOps平台），提高端到端的效率。
那麼如何識别軟體開發、傳遞過程中的浪費呢？通常浪費有如下八種：
實踐3：内建品質——軟體傳遞的品質門禁
從需求、分析、編碼、測試到釋出，每個階段都需要設定品質門禁或者品質關卡。下圖是我們實際項目中應用的DevOps平台端到端的流水線。在每個階段對應設定品質紅線，根據提前設定的規則或标準來判斷是否可通行。
在以往服務的優秀客戶中，東風集團、國金證券也通過攜手嘉為藍鲸DevOps平台實作了品質管控的場景，相關案例介紹歡迎點選閱讀。
軟體質效領航者 | 優秀案例•東風集團DevOps改革項目
軟體質效領航者 | 優秀案例•國金證券DevOps建設項目
實踐4 精益看闆
設計精益看闆時，需要考慮3個核心因素：
如何展現價值？
如何反映協作？
如何暴露問題？
我們可以通過“5步法”，設計精益看闆：
實踐5：改善（Kaizen—日文）
改善的工具方法有很多，我們可以借助DMAIC架構，即：定義（Define）、度量（Measure）、控制（Control）、改進（Improve）和分析（Analyze）。
關于如何用導師與學員對話（輔導套路）來傳授改善套路，具體方式解析請見PPT。
點選下載下傳PPT：内容中心
精選互動問答
問：精益是否是靈活疊代更新？