從新審視故事點

我常說我可能發明了故事點，若是真是這樣，如今我會感到很抱歉。讓咱們一塊兒來探索我如今對故事點的思考。至少有一我的對我所想的很感興趣。 -- Ron Jeffries

固然，故事是極限編程的思想，不是Scrum的。不知何故，Scrum踐行者接受了這個理念。儘管在Scrum官方指南中有關待辦事項的內容，將待辦事項做爲用戶故事是一種廣泛的Scrum實踐。

至少在某種程度上來講，他們是對的。我已經在其餘地方寫了關於故事的常規用法，正如它應該被寫下來同樣。在這裏，咱們將討論的是"故事點"。

在極限編程中，故事最初是用來估算時間的：實現故事須要花費的時間。緊接着咱們來談談"理想天數"，它是用來非正式地描述若是別人讓你盡本身最大努力單獨完成故事需花費的時長。咱們用理想的天數乘於一個"負載因子"轉換獲得實際須要的時間。負載因子一般是3（3天才能完成一個理想天數的工做量）。

咱們剛談到用天數來估算，常常是把"理想"拋開。這將致使的結果是咱們的老闆很疑惑，怎麼是要花費3天來完成原本1天就能夠完成的任務，又或者說，爲何咱們不能用3周來完成50"天"的工做。

我記得，咱們開始稱"理想天數"只是"點"。因此一個故事應該用3個點來估算，這就意味着這個故事須要花費大概9天來我完成。總之，咱們確實也是隻用點來決定多少工做進入一個迭代，因此若是咱們說大概20個點，沒人會反對。

我可能已提出更名字的建議。若是我真這樣作了，如今會感到抱歉。從給個人同事西蒙的電子郵件中，有一些關於目前我對這個話題的想法，他問到：

你真的後悔發明了故事點，或者你只是簡單譴責當他們作相關度量時，沒有正確理解而致使濫用嗎？

我答道：

• 我固然譴責他們濫用；

• 我認爲使用故事點來預測"咱們將何時完成"充其量是個無力的想法；

• 我以爲跟蹤實際與估算的比較充其量是浪費；

• 我以爲比較團隊的估算質量或速率是危險的。

讓咱們更深刻一點。

實際上，一些用來作"敏捷"的方法，以更容易計劃的名義，推薦給各團隊規範化用戶故事點。這表面上看起來很是合乎情理，卻太容易掉進團隊比較的陷阱，組織也是常常這樣作的。

比較

首先，即便他們看起來很像，每一個團隊都有本身的技能和特定工做環境。因此若是他們看兩個貌似同樣的故事，一個團隊說這是個2，另外一個團隊說這是個6，那就不是頗有趣了，固然這樣比較兩個團隊也不是個有效的方法。

如今咱們懷着好奇心來了解這種情況，首先判斷條件是否足夠類似來比較，其次試問估算更高的團隊，是否須要我們能提供的幫助。這樣就很好。隱式或顯式地結束"更慢"團隊的劣勢或以某種方式搞砸------這將是很是糟糕的事，但不幸的倒是很常見的。

我認爲對不少管理者來講，比較兩個產品團隊是件極其誘人的事。在可能的狀況下，拋開故事點的概念，甚至拋開評估點的概念，我認爲也是足夠不可抗拒的。咱們回到如何用更少的估算來開展工做問題上，這裏還有其餘的文章也講到這方面內容的。

跟蹤

對於不少管理者，估算的存在乎味着"實際"的存在，意味着你應該拿估算與實際比較，確保估算與實際相匹配。當估算與實際不匹配時，就意味着人們應該要學習如何更好的估算。

對我來講，真正的敏捷裏最重要的是選擇接下來要作的事，而且當即開展去作。最關鍵的問題是找出最有價值的事作，而且快速實施。快速開展去作，歸結爲去作小部分價值高的和快速迭代。若是不這樣作，故事成本估算幫助不到什麼。

所以，若是估算的存在讓管理者把注意力從價值中移開，取而代之的是改善估算，把精力從快速交付真正有價值的東西轉移。

這讓我以爲估算，無論是點仍是時間，都是浪費！

壓力

有關估算/實際涉及的是老闆們須要"更多"的天然壓力。儘管不少團隊已經完成了，這是不夠的。更多，更多，更多。

交付有價值的東西，最好的方式不是更多、更多、更多，而是頻繁的作有價值的東西。若是咱們把故事分解到"足夠小"替代估算故事，從而達到一直持續平穩地交付有價值的東西。

聚焦在更多的增值。讓團隊在愈來愈大的壓力下作更多的需求，不可避免地會產生一個壞結果：團隊試圖更快速地去作，而忽略代碼質量和測試。他們瞬間開始承載愈來愈多的缺陷，由於持續返工去修復缺陷，甚至因爲代碼質量迅速下滑而放慢速度。事情變得愈來愈糟糕，壓力持續增加，這將演變成一場災難的節奏。

因爲估算至少被捲入過分壓力的投入中，我寧願避免。

我更深刻點：我寧願徹底避免迭代或衝刺計劃。在接下來幾周，咱們不會爲去填補預算而工做，而會由於接下來有幾項最重要的事情清單而作。

預測完成

一種常見的作法是作個基本特性列表，先想一會，而後決定定義咱們產品的下一次發佈。固然，接下來的問題是"這些何時能所有完成？"

沒有人知道這個問題的答案。咱們能夠作不少工做來改善咱們不知道的事，在某些領域和某些時候，這當中的一些事也是值得作的，譬如當一個大的合同等待投標的時候。可是當咱們正忙於開發內部或外部客戶的解決方案時，儘量地頻繁提供少許有價值的東西，而不是等到一般會無限期拖延的全功能一塊兒發佈。

選擇臨近下一次發佈給客戶的日期，儘量地挑選好東西到發佈中，這樣更好。估算故事點或時間阻礙了交付。在我看來，若是可能的話，這最好要避免。

分解（拆分）

那麼問題來了，若是你不喜歡故事估算，那你喜歡什麼呢？好吧，我喜歡故事分解，它是將大的故事點分解成更小的故事點集合，每一個小故事點儘量高的價值，然而只須要不多的時間就能夠完成，理想狀況下，少於一天，也許只是幾個小時。

如今，我不在意與你爭論分解（拆分）時是否必須進行某種估算。若是你或者你團隊的估算只是在腦海裏，沒有告訴任何人，那麼，不管是故事點或時間的估算問題，就不太可能提出來。固然，瞭解故事點"可能足夠小"和"可能不夠小"之間的差別並不等同於知道"三天"和"一天"的差異。

另外，這有個技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是從Neil Killick學的：分解故事直到它只須要一個驗收測試。一個好的故事點只須要不多的實踐。

固然，還有關於估算主題的其餘文章，點擊連接會有超乎你想了解的。

預測未來

可是...難道咱們不該該合理的知道一個產品發佈須要多長時間和估算是否必要嗎？然而也許這不是故事估算。你應該不會把你的需求歸結到故事層面，若這麼幹，貌似是很大程度的浪費。

固然，若是你必需要這麼作，那就這麼作。不管我作什麼或者個人關於你該作什麼的理論，只是理念。最終你須要作的是在本身所處的環境下盡一切可能的成功。只是我以爲能夠有些更好的東西。

• 第一，想一想下一次發佈的一個或多個重要功能。講講這些功能能夠解決什麼問題和什麼樣的軟件能夠幫助解決這些問題。談談能夠解決一些問題的最簡單功能。咱們沒必要要解決全部的問題：一般咱們提供一些解決方案足以推進事情的發展。

• 第二，想一個到那時你以爲能夠構建出一些好的功能點的時間節點。設置最後的期限並開始着手工做。

• 第三，再分解重要的功能故事點並實現它。你應該可以在一天或更容易地實現。只作下一步最重要的：別試圖總是先實現邊邊角角的功能。你應該嘗試這樣的思惟框架"若是作了這個小東西，客戶Jack就會在實際中使用它"。而後，就作這個小東西而且讓客戶Jack試用它。咱們想盡量快的持續傳遞價值。

咱們想把正在作的東西的價值明顯化，讓產品經理或者其餘老闆等不及想看到產品。這樣...咱們就在有或沒有故事估算的狀況下作了正確的事。

總結

若是我真發明了故事點，我如今可能有點很是很差意思。個人確以爲它常常被誤用，致使若是根本不用故事估算的話，就能夠避免不少陷阱。若是故事估算沒有爲你的團隊或者公司提供很大的價值，我建議直接棄用，由於它們是浪費。另外一方面來講，若是你確實喜歡他們，那就繼續！

做者：Ron Jeffries
譯者：謝誼丹
審校：Bob Jiang

• 用戶故事
• 故事點
• 估算

本文首發於 Bob Jiang的博客 ，轉載請聯繫 Bob Jiang