我們應該停止使用故事點和速率嗎？

敏捷社區的專家正在熱議如何使用故事點和速率（Velocity），不少人對使用它們估算和度量總體進度產生了懷疑，打上了問號。大家普遍認為，產生問題的根本原因就是這些度量項往往不是掛羊頭賣狗肉，就是浮于表面被誤用，很少能用在刀刃上。

Joshua Kerievsky詳細記錄了他使用故事點的經驗，以及他們是如何粉飾太平的。在下面的這個例子中，他講述了故事點走向惡性通貨膨脹的過程。

2004年的一天，Jim想要團隊加快開發速率。團隊原本的平均開發速率約為每個迭代完成52個故事點。他們的開發速率可能有幾個點的浮動，但總體保持著平穩。然而Jim要求團隊“全速前進”。僅僅幾周后，團隊開發速率一躍攀升至80點！

我問一個同事這是怎么回事？

她用諷刺的神情看著我：“這幾天在這兒打個噴嚏都算故事點。”我搖了搖頭，吃驚地看著這個成熟的敏捷團隊居然為了讓自己看起來速率加快了，以迅雷不 及掩耳盜鈴之勢膨脹他們的故事點估算。這可是我和兩個優秀的Industrial Logic公司教練一起親自培訓、輔導并審核過的團隊啊！

此次經歷之后，我對故事點和開發速率計算的信心開始動搖了。

Joshua還指出，用故事點來橫向比較團隊是非常拙劣的方式：

這些年來，我聽過多個來自不同公司的經理這樣問：“為什么X團隊每個Sprint可以完成24個故事點，而Y團隊只能完成12個呢？這兩個團隊規模差不多啊，究竟差別在哪兒呢？”

這些經理并沒有把開發速率當成是團隊獨有的能力指標，而是掉入了一個常見的思維陷阱，把開發速率當成了績效度量指標。

在Joshua的博客評論中，Bob Martin大叔進一步確認了這一點：

許多團隊確實在使用故事點時很掙扎。我遇到過有些團隊的項目經理莫名其妙就要求團隊加快速率，企圖不勞而獲，那么團隊只能讓故事點貶值。我也遇到過有的團隊為了討老板歡心捏造開發速率報表，因為老板更熱衷于形式而非內容。對于這樣的團隊，其他的方法可能更靠得住些。

在Scrum Alliance郵件組的討論中，Ron Jeffries就批判了將開發速率作為度量項這一行為。

• 開發速率可能并常常被誤用。
• 開發速率可能并常常被用于攀比。

尤其是這跟主流敏捷思想背道而馳。敏捷實施中，很重要的一點就是要通過優先級來決定先做哪些后做哪些，從而掌控項目，而非緊緊盯住數學公式并致力于讓數字好看。

團隊關注開發速率那么就并不再關注實際價值。我希望我沒發明過開發速率，但我卻這么做了。

沿著這個思路，他進一步做了詳細說明：

我們發現這里的多數問題是關于如何改進估算，讓它們更加精確的。當我們進一步分析，我們注意到團隊會計劃一個完成時間，然而他們會被催促著按時完成所有工作。看得出他們在度量團隊預估的準確性。

我們發現產品負責人只會”遵循計劃“，幾乎不管不顧地分配任務。

只有當產品負責人能夠創造性地使用待辦事項列表，交付盡可能好的產品時，Scrum才算物盡其用。我發現緊盯著估算對此毫無幫助。

Mike Cohn最近發表了一篇博文，介紹了一個非常看重估算的客戶的案例。援引這個客戶的話：

首先，對我而言，至少為了做預算，我需要知道我們的估算可以和實際情況有多接近。當我問投資人要求追加投入時，如果我們只完成了承諾的二分之一，他 們會覺得這是個無底洞。我會處理這些情況，但我需要知道我們有個合理的途徑來獲得一個初步的估算。第二，為了籌集后續資金，我需要了解大概的數目（這是一 項需要不少前置時間的活兒）。如果估算和實際情況相差甚遠，我們就不得不改進，隨后我會去開辟獲得資金的渠道。也就是說，沒有免費的午餐，錢不可能無緣無 故從天而降。我必須有某種水平的度量來反映損益情況并貫穿項目始終。換句話說，我得在項目過程中盯住燃盡圖，關注項目成本。

Vasco Duarte提出了一個故事點的代替方案：通過統計故事數量來做來估算 。 

如果是估算以及監控那些長期項目（提示：這只適用于長期項目，例如在未來至少有三個以上Sprint），你可以假設所有的故事大小都一樣，因此就可以通過度量每個Sprint完成的故事數量來跟蹤進度了。

Mike Cohn也提出來類似的觀點：

我承認用看板的團隊相對較少做很具體的估算。這往往是由于他們已經默認了所有的工作的規模都相當的緣故。

Neil Killick提供了另一種不需要估算的定價方式。他以自己做網站的例子做比照。他的供應商會根據公布的可用預算給出最可能實現的方案，而Neil如果在任何一點上感到不滿意，隨時都可以選擇終止合作。

他認為，這個選擇

不需要估算。隨著項目推進，不斷改進設計、慢慢成形。它擁抱變化，因為我看得到網站的進展。并且這種模式也體現出我的供應商 公司很期待和我密切合作，達成我想要的結果。這種方法也正是為面對特殊風險（按合同規定會虧錢）而準備的，因為他們對自己完成工作的質量信心滿滿，對他們 和客戶建立的良好關系堅信不疑。

你有沒有發現類似開發速率和故事點估算在團隊中助長了不良作風的事情呢？對于社區專家提出的代替方案，讀者，你怎么看？

查看英文原文：Should we stop using Story Points and Velocity ?

來自：InfoQ