精益生產原本是來自于制造業的一個理念，為豐田汽車首創。之后隨著一代代豐田人的豐富和完善，逐漸成為豐田汽車商場制勝的一大法寶。之后隨著精益生產的理念傳到美國，逐漸的發展為一套完整的價值體系。

與此同時，在軟件工程領域，敏捷也逐漸發展成為一套完整的價值觀和方法論的體系。直到有一天，這兩者被同時擺在桌子上的時候，我們才發現，這兩者雖然行業背景不同，關注點也不盡相同，給出的解決方法也不一致，但是在最基本的價值觀上卻可以做到相互融合。由此，精益生產的理念也被引入了軟件工程領域，并逐漸形成Lean-Agile的項目管理理念。現在如果你去搜索“精益 敏捷”，你能看到的往往是這樣的：

這樣的：

還有這樣的：

所以我們可以看到，這兩種思想正在軟件工程領域發生著深度的融合。正所謂他山之石，可以攻玉。作為一個長期浸淫在敏捷開發領域的開發者，精益生產又能帶給我們哪些啟發呢？

我們知道，精益生產的主要目的是為了減少生產過程中的浪費，從而提升企業的整體盈利能力，按照精益生產的理論，生產制造過程中的浪費主要有以下7種：

1.過量生產

2.糾正缺陷

3.多余工序

4.過度庫存

5.物料運輸

6.多余動作

7.等待

投射到軟件開發過程中，這些浪費又分別有著哪些隱喻呢？相應的，我們又能做些什么來減少我們軟件開發過程中的“浪費”，從而提升軟件開發團隊的“整體盈利能力”呢？

過量生產?—?需求鍍金或優先級顛倒

作為一個“有追求”的BA或者Dev，我們總是希望能給用戶提供一個眼前一亮的功能，但是這種強大的“自驅力”反映到軟件開發中的結果卻往往是畫蛇添足。我們花了20%的時間去完成了80%的核心功能，然后再花80%的時間去完成剩下那20%的無用功能（蛇足）。試想一下，如果我們在用20%的時間完成那80%的核心功能之后，及時的與用戶確認，獲取用戶的改進意見或更進一步的需求，反饋回路會比之前短得多，也會避免畫蛇添足給團隊帶來的挫敗感，而這一切恰恰是精益生產中所說的“不多不早剛剛好”。所以我們在聊Product Backlog的時候，如果出現一些產品特性是來自于我們的“Product Vision”，而并沒有與用戶進行任何的確認的時候，我們都應該警惕，我們是不是又在開始“畫蛇添足”了。

?

還有一種情況就是產品特性開發順序的混亂。我相信很少會有團隊會在訂單管理功能還沒開始做之前，先花上3個月的時間實現一套完整的報表功能，因為誰都知道，用戶需要的是能夠用來支持每天運營的功能，能夠讓他們的客戶能夠正常的下單，能夠讓他們真正的掙到錢。但是在實際的工作過程中，我們往往對于某幾個產品特性的優先級無法迅速的達成一致，這個時候體現出來的正是我們對于用戶核心需求和痛點的理解模糊不清。那么這個時候我們應該怎么辦？很簡單，找用戶確認。“嘿，老板，我們現在有這么兩個產品特性，你最想要哪一個？” 是的，就這么簡單。

?

糾正缺陷 — 產品特性在驗收之后才發現bug

我們在說敏捷三角的時候，會提到價值-質量-約束，質量的重要性可見一斑。質量對于我們的用戶的重要性不言而喻，畢竟誰也不希望花了大價錢開發出來的產品動不動就崩潰，動不動就丟失訂單，因為這一切對于我們的用戶來說意味著客戶流失和財務損失。

那么質量對于軟件開發團隊而言意味著什么呢？軟件質量低下，bug頻發對于開發團隊而言就意味著成本的激增。因為這些bug的修復都屬于計劃外的工作，計劃外工作的增加就意味著計劃內工作（新的產品特性）會受到影響。

同時我們經常會說，開發人員同一時間應該只工作在一件事情上，因為工作上下文的切換是會帶來切換成本的。這種上下文的切換越頻繁，這種成本就會越高。我們花45分鐘完成一份數學試卷，再用45分鐘完成一份語文試卷，這不是一件難事。但是如果讓你做5分鐘的數學，再做5分鐘的語文，如此循環下去，我相信在同樣的90分鐘時間內完成這兩份試卷的難度會明顯的提升很多。

同樣的道理，在開發人員正沉浸于一個產品特性的開發的時候，持續的用他3個月前開發的一些特性的bug來打斷他，于是他被迫在多個他自己都不記得如何實現的產品特性的上下文之間來回切換，我想誰也不會指望他手頭新的產品特性的開發能如期完工。而且這些bug修復完了之后，還有一個抓狂的QA需要在這些bug修復后的功能測試之間來回的切換上下文。

?

我們要做的就是在團隊內部養成測試的意識。我們可以制定團隊的單元測試覆蓋率標準，并將功能測試和產品的CI/CD流程進行整合，讓所有不符合測試覆蓋率要求的新特性都無法進入下一個環節。測試人員通過一系列自動化測試的手段提高測試效率，保證每一個新特性的集成都不會破壞已有的功能。通過一些成熟的第三方工具分析代碼的壞味道，并保證每一個新特性的集成不會引入新的壞味道，畢竟今天的壞味道明天可能就是一個bug，誰也無法保證在開發新功能的時候不會觸發別人（很大概率就是他自己）幾個月之前埋下的一個臭彈。

多余工序 — 不必要的流程環節或無意義的會議

產品生產過程中的工序分為三種，一種是產生實際價值的工序，比如汽車焊接，軟件功能的開發，界面的設計等；第二種是不產生實際價值但是卻不得不做的工序，比如汽車出廠前的質檢，軟件上線前的測試等；還有第三種是不產生實際價值，并且通過流程優化之后可以避免的工序，比如說通過優化汽車生產線的布局，可以避免半成品在不同加工車間的搬運和轉移。

而在我們軟件開發的過程當中類似的這種可以避免的工序往往也存在。比如說我們的BA在迭代期間會準備下個迭代要開發的故事卡，有時他會在全部的10張或15張卡全部準備好之后去跟QA做一次kickoff，而這些原本可以通過小批量移交的方式來進行。

有時我們的QA會為一個頁面上一個小小的布局錯誤專門創建一個task，用一套完善的文字描述和截圖來記錄這個“bug”的復現步驟，然后把這個task移交給開發人員。

?

有時候我們會臨時召開一些會議，叫上所有團隊成員，在沒有給他們留出充分的時間做準備的前提下，去討論某一個問題的解決方案。而所有的這一切，其實都可以通過更加輕量化更加優雅的方式去處理。

過度庫存 — 片面的優化某一環節的工作效率

每一個產品特性的交付都會經歷需求-設計-開發-測試-部署等環節，當我們在說提升團隊的工作效率的時候，其實應該從團隊整體的角度來思考。比如說如果我們花了大力氣提升需求分析環節的效率，將需求分析的產出從之前的每個迭代分析10張卡提升到了每個迭代能分析100張卡，然而設計環節的產出仍舊是每個迭代只能設計10張卡，那么結果顯而易見，大量分析完成的卡成為“半成品”進入“需求倉庫”成為“庫存”。當我們某一天做到一張半年前分析的卡時，這張卡還能否符合此時此刻的業務需求，可能就無從得知了。

?

同樣的情形可以發生在這條“產品流水線”上的任何一個環節。所以我們要做的是，評估整條“生產線”上的產出效率，找出制約整條“生產線”效率提升的痛點，進行有針對性的優化，最終使得需求-設計-開發-測試-部署所有環節的產出效率一致，減少這些庫存半成品的產生。

而且我們還要認識到，隨著人員熟練度的提升以及新成員的加入，各個環節的生產效率是一個持續波動的過程，因此這個“生產線調優”的工作將是一個長期持續的過程。

物料運輸 — 分散無序的項目文檔和開發材料

試想一下，如果一個團隊的代碼庫放在GitHub，應用服務器在AWS，數據庫放在自家的數據中心，項目文檔放在項目自己搭建的SVN里，公司的管理文檔放在Google Drive里，團隊的賬號密碼信息用LastPass存儲和分享，系統日志存在SumoLogic，用Jira管理迭代任務......

請問開發人員在開發一個新的產品特性時，一共需要訪問多少個外部系統才能完成他的工作？當一個新入職的同事加入團隊時，他需要多久才能將這些信息匯總到能開始日常的工作？所以我們應當將項目的開發工作所需要使用到的文檔和材料通過wiki等工具有機的管理起來，減少團隊成員在完成日常工作的過程中需要跑好幾個“倉庫”才能備齊所需的全部“原材料”。

?

多余動作 — 交接清單，百科全書式的故事卡

在devops這個概念興起之前，開發人員與運維人員從屬于兩個團隊，在項目開發工作完成之后，代碼會被打包移交給運維團隊去部署和運維，在此過程中，一個大型的項目會有一個交接清單，代碼包，安裝說明，運維手冊林林總總一大堆東西。而現在我們強調要打造全功能團隊，當我們的開發人員能夠完成全部的部署和運維工作之后，我們會發現，所有的這些交接清單都省了，我們再也不用花大把的時間去寫這些文檔了。

同樣的，BA在寫故事卡的的AC過程中，有時也會嘗試將AC寫得如同百科全書一般的盡善盡美，結果后面開發和測試的同事看到這些長篇小說一般的AC時，都不由得會皺一下眉頭。敏捷團隊必須借助迭代評審會議和迭代回顧會議之類的活動，及時的將類似的“不適感”反饋給對應的同事，以便于團隊成員工作方式的持續改進。

等待 — 各個環節之間節奏不統一，團隊成員之間界限過于清晰

生產線上出現等待的原因無非就是各個環節之間節奏不統一，需求和設計的速度跟不上開發的速度，開發的環節必然出現等待。這個問題在過度庫存那個部分有提及。

還有一種情形就是團隊成員之間職責邊界過于清晰，BA只負責分析需求，對測試的工作一無所知，開發只專注于提升前端的開發技能，對后端開發提不起興趣，對于業務需求和測試漠不關心，測試人員只關心測試，對ops的工作一竅不通。于是我們只能祈求這些關鍵角色不要生病，不要休假，否則一旦QA跟女朋友去新馬泰了，ops就只能看著一堆沒有測試的功能干瞪眼了。而如果有一天ops不舒服需要休息兩天，成噸的新特性就無法被部署到生產環境中去了。

?

對于這種情況，我們需要鼓勵團隊成員的融合發展，建立一個全功能的團隊，避免某一項關鍵技能，或某一塊業務的上下文只掌握在某一個團隊成員的手中，此時pair工作會是一個比較好的方式，在分享上下文的同時解決技能單一化的問題。

作者：錦駿
鏈接：https://www.jianshu.com/p/b15e0d6e66c6
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

總結

以上是生活随笔為你收集整理的精益软件过程中七大浪费的应对之道的全部內容，希望文章能夠幫你解決所遇到的問題。

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