l

2012年2月5日 星期日

Scrum 是什麼(12):不要再用focus factor與unplanned items了

February 02 13:37~14:58

螢幕截圖 2015-06-12 08.39.18

 

前情題要:

 

不曉得有多少鄉民跟Teddy一樣都是讀Scrum and XP from the Trenches: How we do Scrum》這本書 長大 來學習Scrum的。這本書寫得很好,但是書中有兩個做法,focus factor與unplanned items,經過Teddy實際實施過後的經驗,再加上2009年去上Certified ScrumMaster課程時親自詢問授課講師所得到的答案,Teddy會建議不要使用。

關於focus factor的解釋請參考「如何估算story point?」這篇,Teddy今天想談的是unplanned items。

這一切的一切,還是要從某鄉民兩個小時之前在Facebook上與Teddy的對話說起:

鄉民:關於bug的問題,如果是外面的人發現的bug,要算在下一個sprint的task嗎?

Teddy:這要看Product Owner如何安排。

鄉民:我們是在當下的sprint加入一個fix bug task,所velocity會變低。

Teddy:我以前儘量不會一收到bug report就馬上去改它,而是會在某個sprint安排一個bug fix的story, 裡面包含所有要fix的bug。這個修bug的story也是要估算story point的,所以不會有作了task但是導致velocity降低的問題。

鄉民:可是如果bug fix task算unplanned item的話,就不算在velocity裡了說。

Teddy:我之前去上Certified ScrumMaster課的時候,上課講師告訴我,任何的task一定要歸屬某一個story。所以我上過課之後,就把unplanned item給取消了,不再採用了。

鄉民:有這種事...

***

Unplanned item就是在sprint planning meeting中沒有被規畫到的工作都可以放到這裡面的某種容器,採用unplanned item有幾個目的:

  • 應付需要立即處裡的突發狀況:例如使用者臨時回報需要立即修復的重大的bug,修這個bug的task沒地方貼只好把它放在所謂的unplanned item這的分類裡面。
  • 不先完成不行的工作:例如,開始實作某個story的時候發現需要先修改另一個既有功能否則做不下去;或是要先安裝一個測試環境才可以完成整個story。

一個sprint的unplanned item數量越多,的確會造成團隊的velocity(每個sprint實際完成的story point稱之為velocity)下降。有人覺得這是採用unplanned item的好處,因為當團隊的velocity下降,在retrospective meeting時團隊就應該要檢討原因並訂出改善的方法,以便日後慢慢減少每個sprint發生unplanned item的次數。但是很多人可能會把unplanned item當成一個「後門」,反正就算是sprint planning meeting忘了列出的工作到時候只要丟到unplanned item就好了,或是忽略品質的重要性,想說反正有人回報bug就丟到unplanned item就好了。

拿掉unplanned item其實會讓整個Scrum的流程變得比較簡單(原本的Scrum其實根本沒有unplanned  item這種東西),也可以強迫團隊重視流程的問題。例如:

  • 應付需要立即處裡的突發狀況:與其反射性地將所有接收到使用者回報的bug立即放到unplanned item中修正而搗亂了原本開發的步驟,拿掉unplanned item之後團隊會先思考,這個bug如果可以等到下個sprint在處裡,那就不要現在立即處理。如果真的一定要立即處理,可以選擇:
    • 寫一個bug fix task然後把這個task貼到某個story裡面(通常是較要性比較高的story這樣才會優先被施工)。
    • 如果修這個bug很花時間,或是需要好幾個task才可以修完,可能需要考慮新增一個story。雖然Scrum強調「sprint開始之後儘量不要調整story」,但是如果遇到非處裡不可的情況還是應該要隨機應變一下,可以把重要性比較低的story暫時移除讓bug fix的story插隊一下。
  • 不先完成不行的工作:看看這些沒被規畫到但是又非得完成的task和哪一個story有關,就貼在那個story上面。

總之,每一個task一定要屬於某一個story就對了。

***

看到這邊鄉民們可能會說,這樣子不是換湯不換藥嗎?不管有沒有unplanned item這個分類,這些未被規劃的工作還是會讓velocity降低啊。沒錯,這就是重點:

  • 如果團隊的velocity經過好幾個sprint之後都還不能穩定下來,就表示某種警訊。還記得Teddy說過「Scrum 本身不能幫你解決問題,但是可以幫你把問題暴露出來」,問題既然暴露出來了,團隊就需要找出問題並謀求改善之道。
  • 既然有沒有unplanned item這個分類都可以把問題暴露出來,那當然是拿掉unplanned item這個分類會比較簡單啊。

***

下一集:〈Scrum 是什麼(13):為什麼不建議使用focus factor?

***

友藏內心獨白:古人有云:盡信書不如無書。

2 則留言:

  1. 多了後門, 很多時候就沒有辦法照章行事了.
    尤其是對PO來說, 更是大開方便之門.
    沒有後門, 那PO就只好來談, 哪些比較不急的, 可以往後挪.

    (啥, 都不能挪, 那...看開發人員要不要加班了. )

    回覆刪除
  2. 多了後門, 很多時候就沒有辦法照章行事了.
    尤其是對PO來說, 更是大開方便之門.
    沒有後門, 那PO就只好來談, 哪些比較不急的, 可以往後挪.

    (啥, 都不能挪, 那...看開發人員要不要加班了. )

    回覆刪除