敏捷是以消除浪費、提高質量為目標的。但是有些時候總能見到一些原教旨主義者指出，重構也是浪費、結對也是浪費、討論也是浪費。然后呢，又有人提出，XX是必要的浪費這種說法。
想了一下，XX是必要的浪費這個說法其實不確切，只能說，這些東西是必要的成本支出。所謂浪費，必須從經濟學角度講才行。不然世間一切都可以帶上這個難看的帽子。
從牛博網最近新來的騙銀老師那里學來一個概念：“經濟學上有個奇怪的概念叫‘冤死的損失’（deadweight loss），英文的直譯是‘未被釋放出來的能量損失’，那是說，有一部分損失，...”誰也沒拿走，“...但因為效率原因，它就那么憑空損失掉了。”
因為聽起來很玄，為了讓大家更好理解，騙銀老師在后面講的一個非常耳熟能詳的例子：
“
我雇了一幫人，天天就負責刨坑，刨了然后填上，然后再刨開，再填上（這例子不荒謬，中國隨處可見），我發給他們工資，這一來一往國民生產總值（GDP）就上去了。看起來誰也沒損失什么，對不對？只是簡單的財富轉移。其實不然，這里面有巨大的浪費，因為這些錢、這些勞力本來可以用在其他更為有效的生產上，可都用來刨坑了，那就是浪費。”（其實個人這個例子還不夠形象，如果挖坑和填坑的不是一批人，他們自己根本就不知道自己做的是浪費的事情，就知道干了活，拿錢，而且還為挖坑和填坑做了很多過程改進，提高工作效率。那就更形象了。）
所以說，您不能因為某些工作做了您能看到效果了，就不稱之為浪費，而有些工作做了您看不到效果就稱之為浪費了，應當反思一下是不是自己眼界不到。
離職將近，我在交接工作之際，因為我最熟，所以要我把依賴我負責模塊的其他模塊的適配器類改至新版。自己搬著Mingle寫了一些故事卡，又用CC寫了一
些持續集成的腳本。接下來，我還會去寫測試用例。整個過程中，沒有一行有效代碼的產出。在以代碼計績效的角度看，我的工作就算是浪費。可是，大家應該知
道，沒有這些東西，先不說我會不會在開發的時候保證質量。就說我離開以后，當產品質量出問題了，誰來保證？我可以根據異常一眼看出問題可能出在哪里，新接手的人能嗎？如果他改了程序，能保證不會按下葫蘆起來瓢嗎？他需要時間去犯錯去學習，這個時間，沒有產生新的價值，這才是真正的浪費。而且這也就成了挖坑-填坑的模式了。
問題反過來了，我做好這個CI的環境走了，來了一個新人接手，會怎樣？一天，系統報異常了。他有我的測試環境，而且，還是可以運行的。他可以很快的寫一個測試用
例，并開始調試，即便他無法理解整個設計，那不妨礙他快速的修復Bug。而且，因為以前的測試用例可以自動運行，他還可以保證自己的修改不會導致之前的功
能出現問題。一個為產品而組織的團隊，離開了某個特定的人，產品仍然可以自我完善，能完成這樣的目標的手法才是最有價值的。
很多人擔心前期花費的時間太多，后期就更沒時間，問題又來了。前期花費的時間多，是浪費掉了，還是合理的用掉了？如果是浪費掉了，自然不應該，如果是合理的用掉了，那是必須的。我們學軟件工程的時候都學過，一個問題發現的越晚，改正他的成本就越高。后期所謂的沒時間，就是因為前期太多問題沒有修正。
說道這個前后期的問題就不得不提最近一次結對的經歷。在我的堅持下，總算完成了一次與同等水平開發人員的結對編程。持續時間有三天。與同等水平的人結對，感覺是不一樣。也發現了很多以前沒有發現的問題。這都是個人問題，脫離我本人就沒有意義了，所以也就不說了。主要說一下心得。這三天的時間里做了一件什么事呢？推翻以前分成兩個模塊的應用，合成一個。兩個人做一件事，大家可以隨時根據今天剩余的時間做工作的調節，精確到小時。因為了解的信息不同，可以快速傳遞，合作互補，當他提出一方案的時候我可以快速告訴他，我這邊沒有問題，減少了嘗試造成的時間浪費。因為兩個人一起做，腦子根本停不下，一個人停了，另一個人還在轉，帶著你不得不進行。一天的有效工作時間在6小時以上。而分開的話，基本上能有3個小時就不錯了。
（中間發生的一點插曲。因為結對開發從不了解的人看來，是一件很浪費時間的事情。所以出現干預結對的現象出現，理由是擔心做不完。我覺得，如果不是堅持的話，就真的做不完了。從現實中看來，強調浪費，很容易被偷歡概念。而偷換概念的人很多人都沒有做過仔細的考慮。純粹的想當然。）