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%
的意思。若真如此，設想資訊從乙個人手裡傳遞到另乙個人手裡，然後再傳遞到下乙個人手裡，再往下傳，還剩多少了？工作的交接也是一樣的道理，經手的人越多，需要交接的地方越多，花費的代價就越高。所以減少交接就是減少浪費。
軟體開發過程中的浪費 詳細設計
詳細設計是v模型或者瀑布開發中的乙個重要的環節。這個階段負責把概要設計進行細化，並為 書寫作出指導。可以說是乙個承上啟下的重要環節。但是現實的情況真的如此嗎？我們來反思一下 1 詳細設計和 的吻合程度有多高？假設在專案中，在測試後修改完畢提交後，並不修改詳細設計，則詳細設計和 之間並不吻合，並且很大...
軟體開發過程中的審查 Review
軟體開發過程中的審查 review 希望別人做些什麼 定義出流程 希望別人做出正確的結果 定義出審查制度 軟體開發專案中包括很多的審查動作,貫穿於整個開發過程。個人認為審查主要有以下目的 1.盡早排查出潛在的問題 potential risk issue 經過其他人的參與，以不同的視角提出不同的看法...
軟體開發過程中的過度設計
在軟體設計過程中，總有以下感慨 1.總以為自己了解了使用者的細節需求 2.在設計階段，花很多時間針對需求中的某些小功能做設計 3.使用者在實際使用中很少使用問題2的 某些小功能 總之，在設計過程中，使用80 的時間處理了20 的不常用的功能，而80 的主要功能，由於在設計階段考慮不周，導致問題百出。...