什麼時候故事會太大?
When is the story too big?
http://agilesoftwaredevelopment.com/blog/peterstev/when-story-too-big
May 14, 2009 by Peter Stevens
不要接受太大的故事是相當標準的建議. 但是你如何知道何時故事對團隊說是太大? 這裡作者列出三個徵兆:
- Past performance indicates you won’t get it done
- The story is large compared to the team capacity for the sprint
- The demo is complicated and / or demos many sub components.
1. 過去效能是未來效能的一個很好的指標
過去效能是一個參考的基礎, 通常又叫坐昨日氣象(“yesterday’s weather”. 如果你的速度是25個故事點數, 並且在上個sprint中, 你的團隊不能夠完成一個13個點數的故事, 這代表你的團隊在目前這個sprint, 同樣也可能無法完成一個13個點數的故事. 所以你必須承認你之前的估算是有問題的, 必須根據你過去效能加以適當的調整.
2. 故事的大小不應該超過sprint的長度
另外一個基準是比較故事和sprint的大小. 我的經驗是, 故事的大小不應該超過sprint大小的40%. 為什麼呢? 因為估算只是估算而已. 如果你的團隊對於要做的領域技術非常純熟, 每個故事標準容忍程度約 +/- 50%. 也就是說4天的故事可能會做到6天, 這都是在你可以容忍的範圍內. 所以如果你sprint的大小是10, 你若是commit故事點數是4, 會留些一些空間來應付錯誤的狀況, 如果你commit故事點數是4你將會有很大的風險, 特別是你還有commit其它的故事.
3. "如何展示" 會讓複雜度變的很清楚
和產品負責人確認故事如何展示. 這展示的方式應該要非常簡單, 並且是可重複的運作流程, 來展示這個功能確實和當初想的一樣. 如果發現有很多運作流程, 則表示這個故事可能非常複雜, 要所有運作流程都正常可能是不小的挑戰.
若是有個故事的展示方法寫著: 'and other flows like story XY' 或是'et cetera'都是非常可疑的, 我堅持要把所有要展示的運作流程都列出來.
當故事的展示流程非常複雜時, 這是一個好的評斷標準, 來決定是否要拆解這個故事.
留言列表
