本文翻譯自：再談故事點數
作者：
Ron Jeffries
極限程式設計理念發起人，敏捷宣言的17位作者之一，第1位極限程式設計教練。
導讀：
本文詳細講述了：作為「故事點數」概念的發明者，Ron 為何不再經常使用點數。他認為「故事點數」存在許多弊端，如：導致惡性競爭和團隊工作的失焦。同時他也給出了弱化點數後的敏捷開發建議。
對正在採用敏捷工作法的團隊來說，本文將帶來新的思考和視角。
本文總計 2640 字，閱讀約需要 8 分鐘。
我或許是那個發明了敏捷估算中「故事點數」概念的人，但我現在為此感到抱歉。本文是我目前對「故事點數」的看法，希望有人會感興趣。
——
Ron Jeffries
首先，「使用者故事」最初是XP（Extreme Programming 極限程式設計）中的概念，而非Scrum的概念。不知何故，後來Scrum框架的實踐者，採納了這個想法。就連官方的《Scrum指南》在介紹「待辦需求 backlog」時，也認為需求應該以「使用者故事」去呈現。一定程度上，這個做法是對的。
我之前寫過一些關於「使用者故事」的內容。不過這篇文章，我們只討論敏捷估算中的「故事點數」，下文簡稱為「點數」。 在XP中，最初估算使用者故事工作量的方法是：實現該需求所需的時間。
首先估一個理想天數，即：如果讓你專心寫這個功能，你需要用幾天。然後，理想天數 x 負面因子 = 實際實施時間。如果負面因子約為3，那麼要完成一個理想日的工作，實際需要3天。
然而在交流中我們通常不會直接說「理想天數」。結果就是，專案經理經常問：你們為什麼要用三天時間才能做完一天的活。換個角度：為什麼我們不能在三週內完成50天的工作？
為了避免內耗，敏捷開發中，我們將「理想天數」歸納為虛指的「點數」。例如：實現一個使用者故事需要3個點的工作量，可能意味著它約需要9天時間。但事實上，
我們本希望僅使用「點數」來控制每次迭代的總工作量
。所以當我們說這個迭代大概能做20個點的需求時，往往沒有人真的反對。
我曾想過給「點數」改名，但現在，我對該問題有了新的想法。直到我的同事西蒙問我：你是真的為發明「點數」而後悔，還是為它們被誤解和濫用而感到遺憾？
我的答案是：
我當然只是對他們被濫用感到遺憾；
我認為用它們來估算「任務完成時間」是一個拙劣的想法；
拿實際進度與估算點數作比較，是徒勞的；
對比不同團隊的估算準確度，是有害的。
更深入觀察會發現，實際上，一些號稱「敏捷」的團隊，正在用「便於規劃」的名義把「故事點數」變成「標準工時」。儘管從表面上看似乎合理，但很容易陷入比拼工作量的陷阱。
陷阱1：攀比
首先，即使需求看起來一樣，每個團隊因為各自的方法、習慣和環境不同，會評出截然不同的點數。
因此，即便兩個看似相同的需求，很可能A團隊需要2個點，而B團隊要6個點。顯然，這並不能直接作比較。
然而管理者卻試圖解決這個問題：先問需求是否可以橫向比較；再探討耗費更多工時的團隊是否需要幫助。這隱含著一個糟糕的判斷：「速度較慢」的團隊更差勁，或正陷入某種困境。
當有兩個團隊並行開發，對許多管理者來說，將二者的工作量進行對比，是一種不可抗拒的誘惑。但這很可能導致「數量高於質量」。因此我決定儘可能少去做工作量的評估。
陷阱2：考評
在許多專案管理者眼裡：點數≈人天。這意味著將點數與實際耗時進行比較，並企圖確保估算點數的準確性。否則，就是開發人員的能力有待提高。這很糟糕。
對我而言，
真正的敏捷開發是：找到最有價值的功能並迅速實現它
。而快速開發，則要求先完成功能中價值最高的需求，再不斷迭代。而估算「點數」，對此幾乎沒有幫助。
相反，「點數」的存在會導致管理層將他們的視線從「故事價值」上移開，而將精力集中在改進工作量的評估精度上。所以我認為：如果使用「點數」分散了團隊對「價值」的注意力，那不如放下這個概念。
陷阱3：壓力
一旦「點數」與實際工時被畫上等號，管理者自然就會施加壓力：他們想要「更多」。團隊要做的事情很多了，但還遠遠不夠，還可以更多更多更多…… 但
輸出價值的最佳途徑不是堆量，而是經常做一些有價值的小需求
。
如果我們不考評工作量，而是將需求切成「足夠小的」切片，那麼我們將可以更平穩地持續交付、傳遞價值。
對數量的過分關注，會阻礙價值的增長
。只追求工作量所帶來的的壓力將不可避免的導致惡果：團隊開發速度看起來快了，但最終質量捉襟見肘。新版本出現了更多缺陷，頻繁修bug減緩迭代速度，程式碼質量迅速下降也將影響質量……事情變得越來越糟，進一步增大壓力，最後滑坡成一場災難。
由此可見，錯誤地使用「點數」會施加錯誤的壓力，所以我寧願避免使用它。更進一步：我甚至不想再使用迭代或Sprint的概念。我們不再花心思填寫未來幾周的工作數量，相反，我們選擇列出那些接下來要做的最重要的事情。
預測完成時間？
過去的迭代規劃是：列一些基本功能，思考如何將它們拼合成產品的下一個版本。緊接著問：什麼時候能做完？答案是：沒人知道。
我們當然可以改善這種不瞭解，但當我們在為內部或外部的客戶開發解決方案時，更好的做法是：
高頻地提供可見的小价值
；而非規劃一個功能上驚天動地，卻永遠無法完成開發的重大版本。
最佳實踐是：為你的客戶選擇下一個版本的截止日期，並在該版本中安排更多的實用功能。
而去預測完成時間，不管你以故事點數、人天，或者任何指標來進行，都會妨礙這一過程。這也是為何我認為，人們應當減少使用「點數」來規劃工作。
故事切片 √
由此衍生出一個新問題：如果我不喜歡「故事點數」，我喜歡什麼？答：我喜歡「故事切片」。
將較大的需求切分成更小的使用者故事，保證每個故事都儘可能地具有高價值，但實現它所需的工作量很少。理想情況下，應該少於一天，甚至只有2-3小時。
我不會與你爭論故事切片是否也要估算工作量。如果你或你的團隊只在自己的腦海中做算，且不告訴任何人，那麼「估算點數」帶來的問題都不會出現。此外，人們對「3天 vs 1天」的感知，和對「需求足夠小 or 不夠小」之間區別的感知，是截然不同的。
未來怎麼做
當然，如果你必須評估工作量，那請繼續進行。但我仍認為有更好的做法：
首先，思考每個版本的核心功能
。討論它們將解決什麼問題，有哪些解決方案，怎麼做MVP……我們不必解決所有存在的問題。事實上，只要能提供一些價值，就足以讓交付順利推進。
其次，確定一個截止日期
，選擇那個你認為可以交付高可用性功能的時間節點。
第三，對重要功能做「故事切片」
。把需求切分成能在一天或更短的時間內完成的工作。把工作重心放在做「下一個最重要的功能」上。不要總去縫補最開始的那個功能，螺絲殼裡做道場。嘗試建立新的思維框架：「客戶老爺實際上會用的一個小點，就是我們要做的功能點」。然後，做個MVP讓客戶去嘗試。
只有這樣，我們才能儘可能快地持續產出價值。 我們希望讓開發工作的價值可見，讓產品負責人和使用者們都迫不及待地想看到我們交付的成品。
無論工作量多少，我們都應該去做對的、有價值的事情。
總而言之
假如確實是我發明了「故事點數」，我現在可能有點抱歉，但不真的後悔。我確實認為「點數」經常被誤用：機械地使用「點數」規劃開發進度，會踩進很多陷阱。
如果「點數」不能為你的團隊提供很大的價值，我建議你不要過於堅持去使用它。另一方面，關於如何用好「故事點數」，我也曾寫過一些別的文章在部落格中你可以參考。
想讀到更多「故事點數」的最佳實踐、認識敏捷開發的不同框架、深入理解敏捷之道嗎？
請關注LigaAI，持續接收更多幹貨分享~
