標準故事點數

最近我聽過幾個問題，關於如何為使用極限編程規劃方法的多個團隊制定標準故事點數機制。希望是讓多個團隊都使用等效的故事點數，這樣一組團隊的三個故事點數的工作量與另一組團隊的三個故事點數的工作量相同。

我認為嘗試提出這一點充其量是價值有限，最壞的情況是危險的。

極限編程的估算系統基於 XpVelocity 和 YesterdaysWeather。這其中固有的概念是，當你進行估算時，你估算的實際單位並不重要 - 重要的是你根據粗略的比較值進行估算，並使用 YesterdaysWeather 進行校準。

在這種情況下，故事點數充當昨日天氣提供的回饋迴路的錨點 - 僅此而已。其中包含了關於團隊任務性質、團隊能力以及團隊是樂觀還是悲觀的估算者的各種假設。一旦你嘗試制定跨團隊的標準，你就會嘗試對所有這些因素進行標準化。對我來說，嘗試這樣做聽起來非常困難，而且我沒有聽說過有人有效地這樣做過。這並不意味著這是不可能的，只是意味著這很難。

危險的一面來自於一旦你擁有跨團隊的標準測量單位，就一定會有人用它來比較團隊的績效。即使每個人都發誓他們不會用於跨團隊測量，但總會有人懷疑最終會發生這種情況。這將導致團隊扭曲他們的測量結果，讓他們看起來完成了更多故事點數。我擔心的是，這會破壞昨日天氣的回饋迴路，並使規劃過程失衡。我總是對這些事情持懷疑態度，因為雖然擁有一種衡量生產力的方法會非常有價值，但我認為軟體的本質是我們 CannotMeasureProductivity。

所以，要值得嘗試，這必須產生一些有價值的好處 - 但我沒有看到任何好處。我聽過的一個原因是幫助人們進入團隊並更快速地估計。但在你相當熟悉問題和目前的程式碼庫之前，你無法在一個新的團隊中估計。當你這樣做時，你還將了解該團隊中故事點的相對大小。我們在 Thoughtworks 的專案之間移動人員，我從未聽過有人抱怨在加入新團隊時由於故事點的差異而導致估計困難。

於 2012 年 5 月 10 日重新發布