“兩打程序員，3年時間，4732個bugs ， 和對非凡軟件的不懈追求”

《夢斷代碼》這本書，是我十幾年前看的，一口氣讀完。當時我還在Cisco（思科）工作，感覺研發(fā)團隊犯過的錯誤，在這本書中基本都能見到。

當年Lotus 1-2-3的設計者Mitchell Kapor，離開Lotus后成立了開源應用基金會(OSAF)，招募了一批很牛的程序員，開發(fā)號稱革命性的下一代個人信息管理系統－－Chandler。這個團隊似乎不缺錢、不缺技術、不缺經驗，但偏偏不能發(fā)布一款看似簡單的軟件。 6年過去了， Chandler 勉強掙扎著發(fā)布了0.7版，花掉幾百萬美元，但最終還是失敗了，夢斷代碼。

在長達6年的馬拉松里面，犯了一系列的錯誤，導致本來很有希望的項目半死不活。 例如，Chandler項目成員決定用P2P架構來共享日歷，但沒有全力設計相關算法或協議，而是花大量時間去討論Chandler的界面，這一拖就是幾個月，最后P2P架構被徹底放棄，這是極大的浪費。像這種做了，然后被推翻了，在軟件研發(fā)中也司空見慣。

上一篇討論了  軟件研發(fā)效能的負面清單：哪項是頭號敵人？ 今天，討論軟件研發(fā)效能的另一面，即軟件效能的反面，造成軟件效能低下的 “ 浪費 ”。浪費可以分為：

• 直接浪費 ：不需要的開發(fā)成本或直接能感受到的浪費，如（沒人使用的代碼；被注釋掉的代碼，從未被使用過的功能、過度測試等；
• 間接浪費 ：不是直接能看到的開發(fā)成本，如低劣的質量、代碼復雜度、溝通效率低等帶來的額外成本。

這里不管它是直接成本，還是間接成本，不看它產生的原因，而是看它產生的結果，我把它總結為十大浪費。

第10大浪費：做的工作沒有及時發(fā)揮效益

例如，寫完的代碼沒有及時提交到代碼庫中去構建，還在開發(fā)人員本地機器中；通過測試的功能還沒有交付給用戶用，相當于在公司的庫存中，沒有產生效益。

第9大浪費：不同角色或不同任務之間的切換

例如，一個人參與多個項目，需要在不同的任務間切換，熟悉過多的業(yè)務和項目背景，經常切換思維、切換虛擬的工作空間，會造成比較多的時間浪費。

第8大浪費：軟件中不必要的交接

軟件中任務的交接，自然會增加學習成本，增加了溝通的成本，雖然在日常軟件研發(fā)中不可避免存在交接，但不必要的交接或過度的交接，都會帶來浪費，例如：

• 人員流動率比較大（如高于20%），老人和新人的工作交接
• 開發(fā)人員和測試人員間的交接，如開發(fā)、測試是兩個相對獨立的團隊；
• 軟件從開發(fā)到部署的交接（如果實施有效的DevOps，這種成本就很低）

第7大浪費：過度的工作（超出范圍）

因為 缺乏有效的流程、文檔和一致性要求等， 工作中沒有準確了解項目或任務的范圍，做了范圍之外的工作，或者不能做到恰到好處，包括過度管理、過度測試、寫了過多的文檔、過度溝通（太多的會議）等。

第6大浪費：等待

許多人等待其他人的工作，例如團隊的溝通協作不夠主動，等待其他人找上門；開發(fā)測試配合不默契，測試等待開發(fā)提交新的版本；各個環(huán)節(jié)銜接不好，中間都會有等待。即使是一個團隊或一項工作內都有等待，例如沒做到持續(xù)測試，中間會有等待。有時測試環(huán)境沒準備好，無法做測試，也會有等待。

第5大浪費： 一而再再而三地重復犯錯

沒有做根因分析，頭痛醫(yī)頭、腳痛醫(yī)腳。團隊中有些人不犯了，但另一些人再犯；某些團隊不犯了，但其它團隊再犯；犯的錯誤可能各種各樣，包括糟糕的計劃、錯誤的文檔版本等。

第4大浪費： 重復造輪子?

市面上已有開源工具或成熟的商業(yè)工具，不是直接拿來用，或直接購買工具等，而是自己開發(fā)。

第3大浪費：返工

由于 缺乏統一規(guī)范、系統復雜、人員能力弱，導致 低劣的質量、產生很多缺陷，造成重新設計、重新寫代碼，都是返工。過度的代碼重構、回歸測試等都歸為返工帶來的浪費。

第2大浪費： 無用的功能和代碼 

無用的功能和代碼，類似“生產過?！保鶕恍祿y計的結果，在現有的軟件應用程序中，多達2/3功能幾乎或從未被使用過。包括 沒人使用的代碼、被注釋掉的代碼等。

第1大浪費： 整個產品方向性錯誤 

對用戶需求、業(yè)務理解的方向性錯誤，整個產品上線后失敗，沒人用。