精益思想（Lean Thinking）在數字化轉型中一直扮演著重要的角色。精益源自20世紀50年代日本豐田發明的生產方法（TPS），即精益生產。基于這套方法論豐田實現了成本效益結合，大大提升了日本汽車的質量與成本優勢，使得世界汽車工業重心開始由美國向日本傾斜。

在之前的文章中，為大家詳細地講解了精益與DevOps的關系及實踐，本文我們邀請到DevOps解決方案架構師黃錦輝，帶來《精益思想在軟件交付中的應用》主題分享，深入挖掘解析精益思想的內涵，以及在軟件交付領域，精益如何實踐應用，一起來看看吧。

01. 為什么需要精益？

在數字化轉型趨勢中，業務敏捷（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和敏捷實踐，但仍然會發現仍面臨著如下挑戰：

① 基本上沒有人能夠說清楚軟件交付全過程，例如從用戶提出需求開始，到最后將產品/服務交付給客戶，會經過哪些步驟和工具，信息怎么傳遞流動

② 在研發過程中做了很多“優化”，軟件交付周期卻沒有明顯的縮短

③ 過度關注在人力方面，忽視了軟件交付過程，導致內部資源利用率雖然有所提升，但整體軟件交付效率實際是有下降的，反而會降低軟件質量。

02. 精益思想與核心原則

1）精益思想的前世今生

20世紀50年代，大野耐一在日本豐田發明了豐田生產系統 (TPS)，創立了高效益、低消耗的生產方式（后被MIT研究團隊稱為“精益生產”），經過多年的實踐使得日本的汽車工業趕超美國。當時精益更多是應用于制造業領域。1996年，書籍《LEAN THINKING》（《精益思想》）出版，這本書高度歸納了精益思想和原則，并將精益方式逐步擴展到制造業以外的領域。隨著2003年《精益軟件開發》的出版，精益思想真正開始應用于軟件領域中。

2）什么是精益IT？

精益IT協會將精益IT定義為：“精益IT是精益制造和精益服務的原則的延伸，用于信息技術產品和服務的開發和管理。其目標是不斷提高IT組織為客戶提供的價值以及IT人員的專業水平?！?/span>

精益IT專注于提高IT人員，IT流程和信息技術，以便為客戶提供更多價值。精益的本質是一種思考和行動的方式。精益IT還提到了如下七個概念，其中“提升客戶價值”，是精益追求的目標；“減少浪費”是精益的核心，即通過不斷地去減少過程中的浪費，增加價值。

3）精益的五個關鍵原則

① 首先，要明確客戶價值，一切價值都是圍繞客戶展開的；

② 其次，基于客戶價值，建立以客戶為中心的價值流；

③ 再次，建立快速的流動機制，消除過程的瓶頸和浪費；

④ 然后，所有的價值流都是圍繞客戶進行的，是由客戶拉動，而不是生產后再推動給客戶;

⑤ 最后，盡可能第一次就把事情做好，在每個階段保障質量，并通過可視化建立反饋，持續改進。

4）精益的核心思想

基于以上五個原則，精益的核心思想包含如下5個方面：

核心1：定義客戶的價值-誰是我們的客戶

價值是由客戶定義，代表了客戶對于特定產品或者服務的需求。我們需要持續關注客戶價值，以及他們從產品或服務中感知到的價值。

核心2：價值流思想-建立客戶視角的系統思維

① 價值流：

是由將產品或者服務從概念到交付給客戶的所有任務和活動組成，包含了所有的信息、工作和物料流。

② 價值流圖（VSM）：

是精益制造或精益企業技術，用于記錄、分析和改進為客戶生產產品或服務所需的信息流或物料流。價值流圖在下文“精益在軟件交付的應用”中，我們會詳細闡述。借助價值流圖，能幫助我們：

• 1. 提供價值交付全周期的視圖；
• 2. 建立客戶視角的系統思維；
• 3. 提供驅動改進的定量數據。價值流會量化很多數據或者指標，可以驅動我們不斷持續地改善。

核心3：流動效率—優于資源效率

我們在整個軟件交付周期中，經常遇到整體交付效率沒有明顯提升的情況，即流動效率低的問題。如何實現端到端快速價值交付？這需要從以資源效率為核心，轉變為以流動效率為核心來組織軟件交付過程。

資源效率，是指從組織內部視角，審視各個獨立環節的產出效率，關注的是內部資源及職能。而流動效率是指從客戶的角度，審視客戶價值順暢流動的程度，關注的是客戶價值。

前置時間：即從用戶提出需求開始，到最終交付給客戶整體價值的端到端的時間。例如，上文舉例的醫院，前置時間為42天。如果去一站式的私人醫院檢查，醫生診斷快速，從初診到確診的檢查報告，排隊等待時間也大大縮短。因為一站式私人醫院關注的是流動效率。

過度局部優化資源效率，可能會帶來額外的工作，你在工作中不斷切換任務，導致整體工作時間增加，使得下一個環節的人或者客戶經常處于等待狀態，流動效率低。

核心4：質量內建—盡早發現并解決問題

在豐田里有個實踐“安燈拉繩”（Andon Cord）。在生產制造過程中，當一線員工發現其中的工序有異常，會拉動手邊的繩子-安燈拉繩，值班經理便會很快看見拉動繩子的員工是在幾號崗位、在車間哪條流水線，這時會和專家一起檢查生產，群策群力。如在特定的時間段解決不了時，便會決定停止整條生產線的運作。

安燈拉繩的做法，強調盡可能在問題出現的第一時間去發現并且解決。如暫時解決不了便會停下生產線，不把問題留著轉移到生產的下一個環節，這也是質量內建的體現。

質量內建，需要3個因素來體現：

① 建立信任的心理安全的環境
整條生產線停止運作的特殊情況，在絕大多數制造業工廠里是很大的事故，而豐田給予信任、心理安全的環境，來保障質量內建的實踐。

② 可視化與透明性
整條生產流水線，以及安燈系統，都是通過可視化方式展示。

③ 群策群力
需要團隊共同決策、一起解決問題。

核心5：持續改善—隨時隨地全員參與

改善，意味著持續改進，不斷否定現狀，尋求更高的水平。無論是在軟件交付過程，還是個人職業生涯，改善的套路提供了一種面對未知的思路，從而漸進式地不斷提升，持續進化。

需注意的是，改善并不是定期改善，而是隨時隨地全員參與。例如當軟件開發中發現可以改善的環節時，應立即去改善。

03. 精益在軟件交付的應用

1）實踐1：價值流圖在軟件中的應用

第一層（最上層）為信息流，即供應商和客戶之間的信息流，中間會經過發布管理過程。其中，信息流的需求，企業內部會用到許多工具，比如需求管理工具，版本工具，自動化工具等。

第二層（中間層）為生產的過程流。例如軟件交付中，會經過需求分析設計、開發、測試、部署、發布投產等流程階段。這里會涉及幾個量化的指標-前置時間、周期時間、處理時間、安裝時間，我們在下文再一一詳細解釋。

第三層（最底層）是根據各個階段里量化的指標，去繪制時間流水線。例如需求分析（第一個凹處水平線）花了0.5小時，等待開發（第二個凸處水平線）花了1天，開發（第三個凹處水平線）用了1.5小時，繼續等待（第四個凸處水平線）花了2天等等，以此類推，前置時間總共花了12.5天，處理時間為3.5天。

量化指標的概念：

① 前置時間（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及直播回顧。

2）實踐2：消除浪費——區分3種活動類型

通過價值流把指標量化提煉出來后，我們下一步要做的是識別浪費，并進行改善。針對不同的活動類型，我們可以采取不同的方式。

① 消除非增值活動
非增值活動即完全不會帶來價值的活動，例如庫存、返工、等待等，這類活動需要直接消除。

② 最小化必要非增值
必要非增值，例如員工進行培訓技能是必要的，但對于客戶來說并不創造直接價值，這類活動需要最小化縮短時間。

③ 優化增值活動
增值活動，例如軟件需求分析、代碼編寫等活動對于客戶是增值的，這類活動需要借助工具平臺（例如DevOps平臺），提高端到端的效率

那么如何識別軟件開發、交付過程中的浪費呢？通常浪費有如下八種：

3）實踐3：內建質量——軟件交付的質量門禁

從需求、分析、編碼、測試到發布，每個階段都需要設定質量門禁或者質量關卡。下圖是我們實際項目中應用的DevOps平臺端到端的流水線。在每個階段對應設置質量紅線，根據提前設定的規則或標準來判斷是否可通行。

4）實踐4 精益看板

設計精益看板時，需要考慮3個核心因素：

① 如何體現價值？

② 如何反映協作？

③ 如何暴露問題？

我們可以通過“5步法”，設計精益看板：

5）實踐5：改善（Kaizen—日文）

改善的工具方法有很多，我們可以借助DMAIC框架，即：定義（Define）、度量（Measure）、控制（Control）、改進（Improve）和分析（Analyze）。

04. 精選互動問答

問：精益是否是敏捷迭代升級？

答：從時間來看，精益思想是遠遠早于敏捷和DevOps。精益思想是對20世紀50年代在豐田里實踐的總結，敏捷是2001年由敏捷聯盟提出，并且制定、發布了《敏捷宣言》，DevOps概念于2009年提出。目前流行的敏捷框架，scrum、SAFe、DevOps，甚至是PMI DA體系，底層思維均依賴或借鑒了精益思想。

在當今數字化轉型中，精益、敏捷、DevOps是相輔相成的，實踐者需要基于自身企業的情境（Context），選擇適合自己的實踐，沒有One Size Fits All的方法。