1. 額外的功能特性

根據Standish Group的調查報告，傳統的軟體開發過程製造了大量人們不需要的功能特性（7% always used，13% often used，16% sometimes used，19% rarely used，45% never used）。每個功能的實現，都要經歷軟體開發的整個生命週期：需求分析、設計、編碼、測試、釋出和維護，這需要耗費大量的人力、物力和財力，如果最終人們將不會用到這些功能，那麼所有的投入都變成了浪費。而這還沒有考慮過多的功能特性帶來的系統複雜度所增加的開銷。所以額外的功能特性是軟體開發過程中最大的浪費。

2. 部分完成的工作（存貨）

在Lean Thinking這本書裡面，Mary Poppendieck把製造業的七大浪費之一“存貨”對應於軟體開發中的需求列表，她這種判斷所處的環境是軟體需求被寫得非常細緻，細緻到可以直接用於程式設計的程度，同時這些細化了的需求又不會立馬被拿去實現，相反它們會在需求列表中等待相當長的一段時間。當然，毫無疑問這是軟體開發中的“存貨”之一，然而我認為這並不是全部存貨。另外還有一些常見的現象是大部分“已編碼完成”的功能不得不等待很長一段時間才會被測試，而被測試了的功能會等待相當長一段時間才拿去被客戶驗收，這些通通都是軟體開發過程中的存貨。它們是第二大的浪費。

3. 額外的步驟（過度處理）

類似的，這種浪費在Lean Thinking中被識別為對需求的過多細化以及不必要的文件工作，我也認同這種說法。同樣我也認為這種說法並不全面，因為額外的步驟（過度處理）不僅僅存在於需求中，還存在於程式碼中。不少程式設計師會在程式碼中去做很多“預防性”工作，譬如預見可能發生的變化或者可能出現的情況，為了為這些變數留有餘地，結果通常是在程式碼中寫一些額外的程式碼。這種做法一方面增加了不必要的複雜性，另外一方面如果“可能的”情況永遠沒有發生，這些程式碼就成了負債。設計模式的出現可能會讓這種問題緩解很多，然而我們還是要處處留意在開發過程中是否進行了過度的處理。

4. 尋找資訊（上下文切換）

在軟體開發過程中，經常要找客戶確認或者澄清需求，要向開發者傳達設計思路和技術要點，要找團隊成員瞭解專案進展情況，要彼此反應遇到的問題以及解決辦法等等，總而言之就是干係人之間彼此需要大量的溝通，所有這些溝通都是資訊傳遞的過程，所以及時準確地傳達資訊是非常重要的。與此同時，開發團隊經常面臨的境地是很難找到客戶進行需求溝通和確認，或者不得不花費很多時間和精力去尋找各種需要的資訊，也經常遇到由誤解造成的尷尬和浪費。團隊用在尋找資訊上面的時間，並不直接創造軟體的價值，所以是一種浪費，應當努力去減少。

我在一些社群中也看到有些人把上下文切換定義為七大浪費之一，仔細思考之後，我認為上下文切換的過程其實也就是及時找到另一類資訊，並且進入狀態的過程，所以它跟尋找資訊的含義是一致的。

5. 軟體缺陷（Defects）

Bug創造價值麼？不，沒有Bug才是客戶所期望的。Bug產生開銷麼？是，發現Bug、報告Bug、定位Bug、修復Bug、驗證Bug等都要花費開銷。Bug是可以避免的麼？大多數Bug都是可以避免的。所以軟體中的缺陷真是徹頭徹尾的浪費，如果能採取適當的措施減少Bug的出現，那必定會節省下來很多用來處理Bug的時間，然後把這些時間用在有價值的事情上面，這一正一負會產生巨大的差別。

6. 等待

等待也包括讓客戶等待。無論是客戶的等待，還是開發團隊內部的互相等待，都是沒有價值的事情。等待也會推遲問題的暴露和解決時間，所以減少等待就是減少浪費。

7. 移交(Handoffs)

據研究一個人若表達能力尚可，大概能表達出70%左右的意思，若對方理解能力尚可，大概能理解70%~80%的意思。若真如此，設想資訊從一個人手裡傳遞到另一個人手裡，然後再傳遞到下一個人手裡，再往下傳，還剩多少了？工作的交接也是一樣的道理，經手的人越多，需要交接的地方越多，花費的代價就越高。所以減少交接就是減少浪費。