轉至http://buzzorange.com/techorange/2015/12/04/5-laws-of-software-estimates/
這篇一定要給客戶看！資深工程師分享：開發估算純屬浪費
編者按：軟體估算往往很扯，就像《人月神話》裡面說的那樣，認為一切都將運作良好，每項任務僅花費它所「應該」花費的時間基本上就是鬼話，但是估算又是不得不做的事情。怎樣才能做好這又扯蛋又不得不做的事情呢？資深的軟體架構師 Steve Smith 總結了軟體估算的 5 大定律，供做開發的、做銷售的各位參考，也方便讓客戶理解一下。
估算是軟體開發的必要之惡。不幸的是，大家往往認為寫新軟體就跟搞建築或者修車差不多，所以軟體工程師也應該像承包商或修理工一樣，事先能夠給出工作量的完美估算。
建築或修車的確能夠做到，因為他們用的材料和手段都是已知的。車險公司事先就知道你的車應該可以走多遠，每一種零部件維修應該需要多少錢。但是定制軟體裡面很多東西都是要從頭做起，而且如何組合、最終如何工作、軟體究竟應該干什麼等這些都是運動目標。一開始的時候路徑和目的都是未知的，所以很難知道什麼時候能幹完。
估算是定制軟體開發的難題，不過還是存在一些普遍規律的：
- 估算第一定律：估算純屬浪費
在估算上花費的時間實際上是沒有產生價值的。在開發者需要多少時間才能完成工作上這是一場零和遊戲—如果估算要求很緊急並且打斷了開發者正常的開發工作的話情況可能會更糟。如果開發者平均每週（40 小時）要花 2-4 小時的時間去進行估算，那就是 5-10% 的生產力損失（因為用來估算的時間本來可以去寫代碼的）。如果開發者是兼職或只能用部分時間寫程式的話情況會更糟糕。
若干年前，微軟的一個部門在不增加任何新資源或者改變軟體工程任務（設計）代碼、測試）執行方式的情況下把生產力提升了 150%。其主要變化是任務估算的時機和方式。諷刺的是，原來大部分的頻繁和及時估算都是管理層要求的，為的是提高透明度，希望看看團隊生產力能夠如何改進。即便這些估算都是粗數量級的估計，但頻繁的估算仍然顯著破壞了團隊的整體生產力。
- 估算第二定律：估算不可互換
軟體估算不可互換，這主要是基於團隊成員不可互換的推論。也就是說，對一個人的估算並不能用來預測另一個人多久才能完成工作。
被迫根據團隊另一位成員的工作來完成估算已經夠糟的了，但更糟的是你被為了拿下單子的銷售做出的估算設定了任務的截止期限。
如果估算者和實現者水平相當甚至在同一團隊工作的話，估算的可轉移性顯然會有改善。像計劃撲克這樣的技術在估算任務時會利用整個團隊的經驗，確保不錯失某些關鍵的考慮因素而導致估算過於樂觀。這有助於確定估算或估算範圍，但是顯然也會消耗數倍（團隊成員規模）的估算時間。
- 估算第三定律：估算是錯的
估算不是承諾。是猜測，而且往往是范圍越大未來的估算活動越深入，出錯的可能性就越大。這又被稱為不確定圓錐。
由於估算較小較近期的任務要比較大較遠期的精確，所以把任務分解是有意義的。理想情況下，用戶可以交互和測試的獨立子功能應該成為估算過程的單元，如果這些是垂直切塊的話，從客戶或產品業主哪裡獲得對新開發的功能快速反饋是可能。排隊論還認為，當系統中的工作很小且規模統一的情況下，吞吐量會得到提升，這進一步支持了把工作分解為較小的、一致的工作事項的做法。
對個人工作事項和項目的估算往往越臨近工作完成就越精確。最精確的估算，就像最精確的天氣預報一樣，告訴你的是昨天發生了什麼，而不是明天的。
- 估算第四定律：估算是暫時的
估算很容易變質。其保質期相對較短。開發者在項目開始前可能估計特定功能需要 1 週的開發時間。等項目開展 3 個月後，知道和拍板了很多事情后，同樣的功能也許就只用幾小時或者 1 個月了，或者由於優先級或方向的原因乾脆放棄了。無論是哪一種情況，估算的價值都很小甚至是負面的，因為估算後太多事情都發生了改變。
為了處理這個問題，一些團隊和開發方法論建議定期對積壓工作的所有事項進行重新估算。然而，儘管這麼做解決了估算容易過期的問題，但卻又會加大第一定律所說的浪費。你是願意團隊對同一批積壓事項重複進行 5、6 次估算卻從不開始工作，還是願意他們每週哪怕提交一項功能也好？最好還是再看看微軟的白皮書，看看重複估算是如何摧毀整個團隊的生產力的。
我們從估算第三定律得知，估算越往後往往越準。也就是說，估算約合理地往後推遲，準確度就可以越高。這跟精益軟體開發的推遲決定直到最後責任時刻原則很接近。估算也應該在最後責任時刻完成，以確保最高的精確度以及最少的重複。某些情況下，「估算」實際上可以在工作完成後進行，這樣精確度可以達到 100%（而且成本幾乎為 0！）。
- 估算第五原則：估算是必要的
儘管前面四條原則說的似乎都是估算的壞處，但估算是必要的。如果對軟體開發的時間和成本沒有概念，企業就無法做出是否開發的決定。
作為應用建設提案或贏得項目的一部分，服務型公司經常必須提供估算。僅僅因為上述定律是正確的並不意味著估算就可以不要了。然而，你可以更好地管理客戶、項目經理、銷售團隊等涉及到的人的期望和花在估算上的時間，在定制軟體估算時讓大家理解這些事實。
關鍵 2,700 秒 你真的就要這麼浪費了嗎？ 圖 / 空中美語提供
- 總結
以上就是軟體估算的五大定律。這些定律基本上適用於我碰到的每一個定制軟體項目。天下沒有免費的午餐，估算也一樣會產生真正的成本，考慮把估算作為軟體開發過程的核心之前必須考慮清楚這一點。一旦項目審批前進行了足夠的高級估算和 ROI 分析，更多的估算工作未必會比實際工作的快速交付產生更多的價值。
（本文轉載自合作夥伴《36Kr》；未經授權，不得轉載）