? ? ? 看到有的團隊在Grooming會議、迭代計劃會議上對Story估算了點數(shù)以后，到了后期發(fā)現(xiàn)點數(shù)當時估算的不準確，于是就來問了：之前這個story是5個點，結(jié)果做到現(xiàn)在了，我們發(fā)現(xiàn)它根本不是5個點的工作，應(yīng)該是13個點，我們是不是要把這個Story的點數(shù)更新一下？
? ? ? ? 嗯，這個請求看起來合情合理。同意嗎？還是不同意？到底是修改呢還是不修改？
? ? ? ? 這其實就回到了敏捷的出發(fā)點，為什么敏捷要不斷得做計劃（迭代計劃會議），為什么要經(jīng)常檢視計劃調(diào)整計劃（每日站會），根本的原因在于敏捷承認，基于軟件開發(fā)的易變性、不確定性、復雜性、模糊性，任何事先的計劃都是不準確的。所以需要不斷得漸進明細去更新計劃，使得之后的計劃能夠越來越接近準確。
? ? ? ? 所以當團隊在啟動迭代時對于迭代內(nèi)的Story的估算（故事點）代表了團隊當時基于對所有信息的了解而形成的對于需求的理解程度。事后來看，它代表了團隊在當時的計劃能力或水平。我們希望團隊在信息不完整的情況下能夠給出一個比較靠譜的計劃，這實際上是需要團隊具備的計劃估算能力。
? ? ? ? 那么怎么衡量團隊計劃能力的高低，其實就拿團隊在迭代完成的故事點數(shù)與承諾的故事點數(shù)的比值就可以得到團隊做計劃的靠譜程度。希望這個比例在90%-110%之間，說明團隊能夠比較好地應(yīng)對這樣的不確定性。
? ? ? ? 比如還拿一開始的例子來說：一個初始估計是5個點的故事，實際做的時候發(fā)現(xiàn)相當于13個點故事的工作量，有兩種情況。一種是這個故事在當前迭代還是完成了，那么團隊也知道了這樣故事的復雜度，下次碰到了類似的故事就自然會估的更準確些。但是這個迭代只完成了團隊一開始認為的5個點的故事。另一種情況是團隊在當前迭代沒有做完，那么這個迭代沒有能夠創(chuàng)造這5個點的價值，知道在后面的迭代中完成這個故事，才能在那個迭代掙到這5個點。而經(jīng)過這么辛苦的努力才掙到5個點，那么下一次，團隊在估算時也會更努力的估算準一些。
? ? ? ? 而反過來，如果團隊隨時調(diào)整故事的點數(shù)，雖然是數(shù)據(jù)準確的，但是不能反映出團隊在做計劃時的估算能力。而且每次迭代完成時，所有的更新后點數(shù)都會是準確的。這樣，團隊就失去的改進的動力，估算不準后面調(diào)唄，這樣的計劃會議就會失去意義，不能變得越來越準，不能起到有效指導團隊工作的目的。團隊的估算能力也不能快速提高。
? ? ? 而JIRA背后的產(chǎn)品經(jīng)理，深知這個道理。于是在形成迭代報告和Velocity報告的時候，Story的點數(shù)總是迭代開始時第一次估算的點數(shù)，后面再怎么修改點數(shù)也是不會反映到這兩個報告里去的。
? ? ? 大家可以試驗下，再好好想想是不是這個道理。
