敏捷中濫用故事點的幾種反模式 - Lloyd Atkinson

• 首先，我對軟體開發行業的總體狀況不甚滿意。
• 其次，我想寫下我認為 "現代 "敏捷的失敗之處（也就是說，它甚至不是宣言中所描述的敏捷），特別是對估算的痴迷，在現實世界中很少有效果。

故事點的誤用
下面是故事點的反模式：

1、沒有意識到故事點是一種估計：儘管有 "故事點估算 "的說法，但在很多情況下，利益相關者似乎完全沒有意識到 "估算 "的部分。在其他情況下，分配的故事點價值往往被認為是實現積壓專案所需的確切工作量。

2、迫使或脅迫開發人員選擇一個較低的數字。對開發人員施加壓力，以使他們感到除了 "估計 "一個較低的工作量外別無選擇，以便不受影響，避免被挑出的壓力。更糟糕的是，在衝刺結束時，當工作 "耗時 "超過估計時，就會指責開發人員。

3、立即對高或低的數字打折扣。與上一點類似。立即不考慮任何與其他團隊成員相比屬於異常的估計。一個與平均水平大相徑庭的分數通常意味著兩件事中的一件--要麼他們沒有理解工作的範圍，要麼他們對任務有獨特的見解和關注。一些利益相關者忽略了這些見解和關注，因為它們不方便。

4、根據總分來比較和評判開發者的工作量。這是一種可怕的做法，只會導致怨恨和對工作量的不公平表述。有時，一個開發者完成了許多估算值較小的任務，卻被認為比一個完成了估算值較高、需要較長時間才能實現的任務的開發者做了更多工作。這兩個開發者都有貢獻，但其中一個幾乎沒有得到承認。

5、把故事點的估計當作不可改變的事實。一旦就一個故事有多少分達成了協議，就沒有辦法在沒有不必要的戲劇性和爭論的情況下，隨著更多的發現更新它的價值。當然，情況不應該是這樣的，因為改變應該是宣言的一部分。這不可避免地導致每個人都估計出更高的價值，以便獲得喘息的機會。

"應對變化勝過遵循計劃" - 敏捷軟體開發的宣言

6、當開發人員意識到一個故事被高估或低估時，他們會責備他們。與上一點類似。勸阻和詆譭開發人員的估計，往往是定期進行的。這需要停止。

7、為了決定一個故事應該是1分還是2分而進行30分鐘以上的辯論。漫長而持久的討論有時是需要的，這就是生活和開發的本質。也許需要考慮更大的系統架構，或者擔心某種方法會導致技術債務和高度耦合的程式碼。另一方面，一些圍繞一個 "簡單 "的任務是否應該被分配1分或2分等的爭論是很荒謬的，是在浪費時間和耐心。

8、期望每個衝刺階段都有相同的 "速度"。這個問題比較微妙，似乎是在不知不覺中悄悄出現的--至少在幾個衝刺完成之後。它可能是微妙的，但它是一種使人衰弱的做法，隨著時間的推移，只會使團隊和其成員精疲力竭。這可以透過多種方式表現出來，通常是同時進行的。將每個衝刺階段的故事點的具體數量作為強制目標。調整故事點來 "適應 "這個目標。從積壓專案中引入額外的專案來 "適應 "目標，從而增加開發人員的工作負擔。

9、故意估計不準確的故事點，以幫助建立一個 "完美 "的燃燒圖。與上一點類似，但需要特別指出的是。這裡有幾個角度在起作用。

• 1) 開發人員只是想工作，並且厭倦了被責罵，所以 "估計 "了一個故事點，這將使scrum master滿意。
• 2）ticket管理員被問及為什麼他們的團隊沒有一個完美的燃燒圖，於是將故事點揉成高管們想聽到和看到的東西。即使燒燬圖是完全不準確的，只要它是一條完美的直線，對於 "做敏捷 "的組織來說，這似乎就是最重要的。