估算實踐是浪費嗎？

軟體的“估算”，這個有年頭的老大難問題，最近在敏捷社群內引起了有趣的討論。J.B. Rainsberger 、Arlo Belshee、Josh Kerievsky、David Anderson和其他人提出這樣一個問題：“估算真的有必要嗎？”

著名的敏捷專家J.B. Rainsberger在Yahoo的XP討論組中發起了一個有趣的討論，質疑在敏捷軟體專案中做估算的必要性。J.B. Rainsberger與2008 Gordon Pask兩位中獎者之一Arlo Belshee對這個話題有過談話，他是這樣詳細講述的：

［Arlo］對我講了一些他完成的研究和實踐，主要是關於成本估算的，關鍵在於他的研究和實踐中不做這些估算。他的觀點是，或者是我領悟到的是，在做出和管理成本估算上付出的精力要超出擁有這些估算帶來的好處。

Mike Hill加入了討論並指出，Industrial Logic公司的傢伙們在開發自己的敏捷eLearning產品時，已經開始朝不做估算的方向轉變了：

對我們自己的工作來說，純粹的“拉”模式就已經很好用了。客戶會將需求按優先順序排序，並放到“需求棧”中。我們從棧中“拉”出位於頂端的故事並進行實現。規劃會議的規模越來越小，大家都把精力放在最重要的任務之上。

Industrial Logic的創始人Josh Kerievsky在Agile 2008大會中作了題為“被認為是浪費的估算”的演講，並涉及很多細節。他解釋了大家是如何通過交付更小、更頻繁的“微釋出版本”來取得成功的，這樣大家可使用“點數和速度”方式時積累下來的“直覺”來更高效地開發，而且不必再花時間去在卡片上寫數字，做算術題。

不久前，Amit Rathore接觸了類似的想法。Rathore描述了這樣一個流程，接下來要開發的最重要的需求，將被打散成同樣大小的故事（大概耗時幾天），並會在下個迭代中按照優先順序順序展開開發：

訣竅在於：每個故事的工作量不應該超過1-3天。對下一個需求也做同樣的事情，一直這樣做，直到這些故事把兩週內的時間都安排滿。

Rathore解釋了為什麼這樣做不只減少了“浪費”，而且在很多方面都增加了價值：

這種做法帶來了節省時間和精力的有益副作用。能夠真正掌控開發流程，是真正的價值所在。小故事允許在必要時做出改變，在需要時可以從待辦事項列表（backlog）中拉出來，任何時候有業務需求都可新增新的小故事。它也可以讓團隊以更快的速度前進，因為開發小塊增量程式碼很容易，測試也方便，將小的版本釋出給使用者也變得輕鬆。

最後，強制要求每個故事必須保持小規模，大家就會在開始程式設計之前深入思考需求。這也可以強制團隊將需求拆分成一個個可以進行增量開發的小片段，並且完全可以避免出現總是剩個小尾巴開發不完的故事。

David Anderson在很長時間之前就做出了類似的評論，並且從那時起就非常積極地參與了“軟體的看板”運動。這項運動與Belshee、Kerievsky和Rathore討論的想法有非常密切的聯絡。

從多個角度觀察，也許有人會問：“真的沒有進行估算嗎？”這也是J.B.曾經思考過的問題。Kerievsky和Anderson認為這種過程其實近乎於“直覺”，Rathore認為故事的“大小相當”。也許不是，但是這樣做是好是壞？問題真的應該是“沒有估算？”，還是“沒有數字？”還是別的什麼？

檢視英文原文：Is Estimating A Wasteful Practice?

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-429881/，如需轉載，請註明出處，否則將追究法律責任。