精益（Lean）思想來自制造業，21 世紀初由Tom 和Mary Poppendieck 引入軟件開發領域，精益的很多思想也被認為是對軟件行業有參考價值。與Scrum所提供的的過程管理框架不同，精益更多體現為一種思維方式，精益的思維方式也常被稱為精益思維（Lean Thinking）。

1. 精益思想

精益是敏捷開發的一個重要部分。當把精益制造的一些思想應用到軟件開發中時，我們從敏捷開發的其他組成部分中借鑒了一些東西。和敏捷開發一樣，精益思想也包含一些價值觀，這些價值觀中的一部分入盡快交付、增強學習等與敏捷思想完全一致，但也有有一些思想代表著精益的特有思維，最具代表性的就是消除浪費，即找出那些不能直接幫助你創造出有價值軟件的工作，把它們從項目當中去掉。關于軟件研發過程中的浪費現象可以總結為：

• 部分完成的工作：部分完成但沒有最終落地的工作?
• 未應用特性：開發完成但沒有被客戶應用的特性
• 額外過程：開發過程中不需要的流程和中間產物
• 再次學習：人員、環節變動導致反復重新學習
• 信息移交：隱性知識信息的傳遞總是伴隨信息丟失
• 任務切換：多任務工作會導致效率下降
• 資源依賴：因任務或資源相互依賴而導致工作停滯
• 系統缺陷：解決缺陷活動本身就是浪費

對這些浪費現象的分析思想來自于豐田制造系統（TPS），并在軟件行業中得到映射，精益軟件開發過程的倡導者們雖然為我們總結了這些浪費現象，但對如何識別這些浪費進而消除和壓縮這些浪費都沒有提供很明確的實踐方法。我們需要在日常研發過程中觀察這些浪費現象進而找到消除和壓縮實際研發過程浪費的工作方法。

2. 精益中的管道管理

在《敏捷軟件開發工具》一書中推薦了一種簡單的方法來幫助你找出浪費，這種方法就叫作價值流圖（Value Stream Map）。跟其他精益技巧一樣，價值流示意圖源于制造業，但是它同樣適用于軟件團隊，如圖8-14所示的就是一個典型的價值流圖。

要想得到類似上圖中的價值流圖也比較簡單，首先從團隊已經開發并交付了的一個產品功能開始，回想這個功能單元從設想到交付經歷了哪些步驟。在紙上為每一個步驟畫一個方框，用箭頭把各個方框連起來。接下來，估計一下完成第一步需要多少時間以及第一步完成后要等多長時間才能開始第二步。對每個步驟進行相同的估計，并且在方框的下方劃線來表示工作和等待的時間。

價值流示意圖清晰地顯示了該流程中涉及多少等待的時間，從團隊開始改項目到最終交付，一共花了XX天。在這XX 天中，有XX天花在了等待而不是工作上。這些等待時間可能是多種原因導致的：需求文檔可能需要很長時間才能送交所有的評審者；或者工時估計會議必須延后，因為大家已經有其他安排了等等。價值流示意圖展示了對該特性的各種延遲所造成的累加效果，看到這種整體的影響，可以幫助你進一步探究哪些延遲是浪費，哪些是必要的。

結合管道理論，實際上圖中的每一個都可以看做是一個管道，所以價值流圖就是各個管道的負載流轉圖。如果下一個管道處于等待上一個管道的結果，那么這個管道就處于空置狀態，而如果某一個管道上的開發任務與其他管道上的開發任務比例嚴重不匹配，也就會導致因為管道之間數據流轉不平衡導致浪費。我們可以經?？吹介_發過程中出現如下的不良現象：

• 讓每個人確認某規格文檔要花很長時間，而與此同時開發人員則坐在那干等著項目開工。甫一開工，他們就已經落后進度了。
• 開發到一半，開發團隊意識到軟件設計或架構的一個重要部分需要更改，但是這會導致非常嚴重的問題，因為有很多其他部分依賴它。
• 質量控制團隊要等到每一個特性都開發完畢才開始測試軟件。質量控制團隊發現了一個嚴重的bug 或者一個嚴重的性能問題，而開發團隊不得不進行搶修。
• 分析和設計花費的時間過長，導致進入編碼階段時，每個人都需要加班加點地趕工期。
• 即使是對軟件規格、文檔或者計劃的最小修改都需要經過一個冗長的修改控制流程。大家為了繞過該流程，于是甚至把大型的、顛覆式的修改都放到bug 跟蹤系統里面。

基于價值流圖和管道理論，我們可以使用拉動式（Pull）系統幫助團隊消除以上問題。所謂拉動式系統，指的是通過使用隊列或緩沖區來消除約束的一種運作項目的方法或流程。它也源自日本的汽車制造業，但對于開發軟件也非常有用，原因并不意外，跟它對制造業有用的原因相同。與其讓用戶、經理或者項目負責人把任務、特性、請求“推送”給開發團隊，不如讓他們把這些請求送入一個隊列，由開發團隊自己從該隊列中拉取。當工作發生堆積并在項目中途導致分配不均衡時，他們可以創建一個緩沖區來解決。開發團隊在整個項目中可能會用到好幾個不同的隊列和緩沖區。事實表明，這是一種減少等待時間、消除浪費的有效方法，同時也是幫助用戶、經理、產品所有者和軟件團隊決定開發什么樣軟件的有效方法。

下面我們舉一個拉動式系統如何解決一個熟悉問題的例子：軟件團隊需要等待所有的特性都寫入一個大型規格文檔，而后者還必須要經過一個冗長的審核流程?；蛟S該流程為的是征求每個人的意見；也許它不過是那些不敢真正承諾的老板或利益干系人的一種保護自己的手段；或者它干脆就是公司一直以來習慣的做事方法，從來沒人想到它其實是一種浪費。如果我們用一個拉動式系統來替換它，會是個什么樣子呢？

建立一個拉動式系統的第一步是把工作分解成小型的、可供拉取的塊。也就是說，不要編寫一個大型的規格文檔，而要把系統分解為最小可交付特性，比如一個個獨立的用戶故事，可能還有針對每個故事的少量文檔。這些故事可以單獨地進行審批。一般來講，當一個規格文檔審查流程長時間停滯不前時，原因通常是大家對某些特性有不同看法。對每個可交付特性進行單獨的審批應該至少能夠讓一部分特性快速得到批準。只要有一個可交付特性通過了批準，開發團隊就可以開始進入開發階段。

拉動式系統可以很好地消除工作的不均衡并防止團隊的超負荷工作。上述關于拉動式系統的思想和做法體現的正是8.1.2節中介紹的管道負載分析方法，可以認為精益思想也是管理理論的一種具體表現形式。

3. 識別浪費的其他方法

除了價值流圖，還有其他一些方法可以用于識別開發過程中的浪費：

（1）項目輸入過濾

研發過程通常面向產品，而企業級應用或半互聯網半企業級應用的產品最終通過項目進行實施和落地，這樣項目線就成為研發過程的一個重要輸入，而項目經理們站在項目線和客戶的立場上提出來的需求和計劃往往會和產品線、研發線有一定出入。如果本不應該進入研發環節的輸入最終進入了研發環節就勢必會導致浪費。如何通過規劃和分析去把控來自項目上的輸入，讓項目線需求能夠盡量和產品線一致是降低研發成本、消除浪費的一個重要方面，所以項目輸入也是我們尋找浪費的一個來源。

（2）會議聚焦

我們不得不經常召開這種或那種會議，那開會是一種浪費嗎？很多時候是的。會造成浪費的會議通常會有一些共性，典型的有：

• 輸入輸出不明確
• 缺少主持人或主持人不善于引導
• 會議不是結果導向、無法形成有效決策
• 會議議程空泛而不能收斂
• 會議雖然能達成一致，但沒有具體工作安排和責任人制度
• 即使有工作安排但缺乏跟蹤和監控機制
• 會議相關的資料沒有充分準備，也沒有提前交付到參會人員

具有上述特點的會議很大程度上不會有實質性的成果，開完一次之后還需要開第二次，如果把握不好浪費的不但是時間還是團隊的氣氛，需要進行分析和識別，看看我們每天的會議中是否具有以上問題。

（3）數據傳遞有效性對比

目前主流的研發管理方法論中普遍認為溝通和協作是研發成功的關鍵性因素，而溝通和協作的背后體現的實際上就是數據傳遞過程的有效性。如果有兩個研發團隊，其中一個團隊中數據從團隊中的一個人傳遞到另一個人的過程無論在時間上或空間上都比另一個團隊有效，那兩個團隊的戰斗力無疑是不一樣的。數據傳遞在溝通模式、媒介、工具等各個方面都可能存在效率不高甚至不合理的地方，浪費也就在這些地方不斷的滋長，從而消耗著研發團隊的戰斗力。

（4）管理活動梳理

有人說團隊如果足夠自組織（Self-Organization），那我們就不需要管理。這句話雖然聽起來有一定道理，但未必太過虛無縹緲。但從管理工作本身入手分析其在工作流程、文檔管理、任務分配等各個方面上是否存在冗余或者不合理的管理活動確實不失為一種識別浪費的實踐。管理是需要成本的，管理做的好、做的精細更加需要成本，但管理過程本身也可能像代碼一樣需要隨著研發過程和團隊的演變不斷進行重構，重構的前提也就是需要我們對管理活動進行分析和梳理，找出其中的浪費之處并進行消除或壓縮。

（5）流程執行力

無論是好的管理模式和理念，還是適合團隊的研發模型，要想取得令人滿意的效果，歸根揭底還是需要執行力。執行力來自很多方面，如合理的團隊組織架構、優秀的人才、高效的工具、良好的團隊氣氛等，這些通常都不是技術所能起決定作用的領域，卻實實在在影響著團隊的執行力。流程本身可能是合適的，但因為執行的人不行、或因為工具使用不當導致效率降低，這通常都是屬于無法避免但是需要進行壓縮的浪費形式。

通過識別，團隊中的浪費現象已經攤在大家面前。其中有很大一部分的浪費屬于存粹浪費，這些浪費需要通過一定的思路和工作模式進行消除；而對有些浪費通常是必要的，也是不可避免的，對這些浪費而言，我們的思路是盡量進行壓縮。關于如何消除存粹的浪費以及如何如何壓縮必要的浪費我們會另起一篇文章詳細討論。

?

如果對文章感興趣，可以關注我的微信公眾號：程序員向架構師轉型，或掃描下面的二維碼。

我出版了《系統架構設計：程序員向架構師轉型之路》、《向技術管理者轉型：軟件開發人員跨越行業、技術、管理的轉型思維與實踐》、《微服務設計原理與架構》、《微服務架構實戰》等書籍，并翻譯有《深入RabbitMQ》和《Spring5響應式編程實戰》，歡迎交流。

?

總結

以上是生活随笔為你收集整理的敏捷方法 - 精益思想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。