不少團隊在執行 Scrum 時, 常常無法在 sprint 內完成原先規劃的東西, 因此他們想拋棄 Scrum, 轉向 Kanban 的陣營, 這是對的嗎? Sprint 是不好的嗎? 讓我們來聊聊這個問題.

 

1280px-Scrum_process.svg  


很多人之所以無法在 sprint 內完成原先規劃的東西, 不外乎有以下主要原因:

1. 不知如何切割 user story
這裡是能力問題, 通常是大家沒有能力, 不知道如何把 user story 切的小小的, 讓它可以放到一個 sprint 中完成. 因此這不是 sprint 的問題, 而是大家不會切.

2. 有些 user story 的特性是不容易在一個 sprint 內完成
老實說, 有些 story 確實不容易切, 像是 installation 或是 migration, 這些東西不容易拆解, 或者是拆解的代價太大. 在這種狀況下如果我們硬是套用 sprint, 變成是為做而做, 這樣反而讓團隊效率變差

3. 評估老是不準
正確來說評估並沒有所謂的單一數字的答案, 也就是說評估的答案需要伴隨著機率, 例如: 如果你說 2 天做完, 那它的成功的機率是 80%; 如果給你 5 天的話, 那做完的機率可能就是 95%. 可是通常老闆並不會這麼想, 老是叫你給個標準答案, 當然是只有錯的份. 

另外一件更糟的事, 就是在早期資訊不充足下, 就要叫你給個答案, 這也是另一個不準的原因, 沒人可以在資訊不夠的狀況下, 能夠有準確率很高的 estimation.

還有啦, 通常會估不準, 另一個原因可能是東西太大了, 也就是第一點的問題沒能力解決, 導致伴隨評估也沒有辦法準.



因此根據以上幾種原因, 用 sprint 來規範哪些東西要在這時間內做完, 往往是失敗收場的狀況居多, 並且也容易導致團隊對 scrum or sprint 失去信心. 

如果我們把 sprint 想成只是週期性檢查多了多少, 以及有個時間檢討以前做的事情, 這會比較健康. 會比強迫大家一定要在 sprint 做完有意義多了. 所以不管用不用 sprint, 我會建議以下事情仍然要繼續進行:

1. 持續交付
即使有些東西在一個 sprint 內做不完, 但是你還是要保持持續交付一些項目, 讓團隊能夠及早得到一些回饋, 也讓相關利害關係人能夠安心. 而不是通通擠到最後才交卷.

2. 建立調整和回饋的迴圈
在 scrum sprint 中會進行規劃會議和回顧會議, 讓我們可以根據上個 sprint 的結果, 來挑整自己的腳步, 使得我們更接近想要達到的目標.

3. 持續精煉需求
需求這件事情需要持續條理的, 也就是說你除了看這個 sprint 的需求外, 你必須也看看下幾個 sprint 的需求, 對他們做些整理, 可能是做些分析, 或者是把它們拆解成更小的項目. 這樣你才能知道短期的未來有什麼風險; 並且也讓之後真的要處理時, 不至於連一點 idea 都沒有.

所以重點不是 sprint, 而是該做的事情要做, 該有的能力還是培養 ….

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()