【Scrum規劃會議】(四)撰寫Task與回顧檢驗
在Story評分完之後,就要進入下一個重頭戲,也是開發團隊最重要的任務「撰寫Task」,也就是列出自己的「待辦清單」。
2022.03 更新版請點此:(四)如何撰寫工作計畫,並總結規劃
參考最新版的Scrum手冊,修正一些觀念與描述用詞,希望大家會喜歡。
撰寫Task的基本概念
從Task的撰寫開始,主要都是開發團隊的工作了,一般而言大概會花2~3小時來進行。
撰寫Task,簡單來說就是「拆解工作步驟」,把工作任務拆解小至0.5~2小時的單位(依據職業特性可能有所差異,但千萬別超過5小時)。而撰寫的大方向是:
「當把這些Task完成後,就可以達到Story所寫的Criteria與目標。」
通常,寫出來的Task除了代辦事項本身,還會加上是誰要來做、做的時間多久(但我對這一點還是有點存疑,因為這似乎過度在意細節,並會導致團隊彈性降低,不過我們團隊為了方便分配,還是選擇了加上這兩個項目。)
什麼是好的TASK?寫出工作當下的「動態感」
如果從來沒有詳細列出自己代辦項目的人,在寫Task時一定會有些困擾。我覺得用大家耳熟能詳的例子,可以很好地說明,怎樣算是一個好的Task。
「如果,你要把大象放進冰箱裡,要怎麼做?」
如果是第一次寫有,有些人可能會寫:
Task 1-「把大象放進冰箱」
但這樣在估計時間、討論的時候,其實跟沒寫差不多。因為這樣的Story和Task根本就長得差不多。所以最好加入更多的「動作」與「細節」:
Task 1-「把冰箱的門打開」
Task 2-「把大象放進冰箱」
Task 3-「把冰箱的門關上」
簡單來說,就是寫完的TASK要感覺它會動一樣。不要怕把Task寫得太細,因為寫得細,代表你對Story的掌握度很高。
以我的經驗,只要分數超過5分,Task如果寫不到5個,時間一定會比預期想得還多,而且也很可能做錯。
寫出動態感還有另一個好處,就是當工作足夠小、足夠多、足夠明確,團隊就有互助的可能(因為別人可以很清楚知道,哪一部分可以順手幫忙)。在事後回顧檢討時,也可以辨認出究竟是哪一個細節,使得Story遲遲無法完成。
只寫自己要做的Task,反映實際執行狀況
有一件事情一定要注意到,就是千萬千萬別幫人寫Task,因為就算你幫別人寫了,那個Task也往往預估錯誤、無法執行。
舉例來說,如果現在的Story有一部分是要「蒐集下Facebook廣告的規則」,你可能可以幫別人寫「用Google查詢-2hr」,但別忘了,真正要執行的人可以選擇「詢問身邊專業的廣告從業者-1hr」。
同樣一件事情,可能有不同的做法,但無論如何,都要交由執行者來親自撰寫Task,這也是執行者在SCRUM中該有的決定權。
.
一個Task就只由一個人來做,反映正確工時
我們要注意到一件事情,就是「一個Task就只由一個人來做」。
「如果是2個人要做一樣的事,就是2個task;5個人要做,就是5個task」
依據這樣的原則,你會發現開會真的超花時間,因為一個會議可能有3、5個人參與,每多一個人,就必須花團隊的多1小時的時間。
也是因為依據「一個Task就只由一個人來做」的方式列出Task後,就可以很清楚地知道時間都跑去哪了。
我們團隊也是從列出Task開始之後意識到一件事情,如果對會議不會有太大貢獻,那這個人就別來開會比較好。另外,因為開會占用的時數很多,也讓我們開始思考,這個會到底要不要開,還是由一個人決定就好?
總之,把Task寫出來,最大的好處就是:
「我們會更謹慎選擇,到底要不要做這件事情。」
3個問題,進行最後檢驗
在撰寫完Task之後,就要來Review成果了,我覺得有三種問題,可以幫助我們把行動調整到更好的狀態,並且走一些冤枉路(當然,這三個問題最好在撰寫Task的期間,就不斷提出來。)
1.為什麼這樣做,可以達到Criteria?
當大家寫完Task之後,有一件事情我覺得非常值得做,就是回過頭檢視Story與Task的關係。
前面有提到,Task大原則是做完之後,就可以達到Story的Criteria。所以理當在最後回過頭來看看,如果完成了這些Task,是否真的可以達到Criteria?
只有當這件事是肯定的,安排了事情、執行任務才會有意義。
.
2.為什麼這樣做,是否與目標一致?
有個很特別的情況,就是我們所列的Criteria和目標(願景)之間,通常會有一點點的小落差。
即便完成Criteria代表的Story的完成,但Story完成能不能達到目標,其實並沒那麼好從Criteria中看出來,在最後的檢視中,我們可以透過Task的檢視,來看看我們是不是正在往目標前進。
.
3.有沒有更快、更省、效果更好的方式?
既然要執行SCRUM,永遠都該保持彈性、速度、協作,而為了達到這些狀態,在寫Task時可以有些技巧。就是跨組協作,並讓PO、SM質疑Task。
跨組協作的意思是,不論是否要參與Story的執行,都可以融合各個專業來想想,有沒有更快、更省、更好的方法能完成目標。
我們最常發生的例子是,營運部門有的時候需要製作一些表格、數據,但程式部門看到後,往往會知道怎麼更快做好,有些甚至已經有既有的數據了。他們就可以及時伸出援手。
PO、SM質疑Task並不是要否定的意思,準確來說是保持的好奇心來詢問DV所寫的Task。可以問說「有沒有更省力的方式?」、「為什麼會想用這個方法?」、「會不會想嘗試新做法呢?」。
因為PO、SM無論在何時何地,都要扮演一個激發進步的角色,在規劃會議中,Task適時提問則能大大幫助DV成長。
宣布這次衝刺期、預計拿的分數、要做的事情
前一篇有提到,評分完的結尾是簡單的宣布衝刺期的狀況。
「這次的衝刺期為10天,我們將比上次進步約50%,總共有23個Story、一共150分的任務要完成。衝刺的目標,是希望讓我們網站的流量獲得10%左右的提升。」
在Task寫完後,規劃會議也差不多來到尾聲,可以補上一些提醒:
「這個待辦清單,就是為了目標要做的事情,但要注意的是,隨時保持彈性、幫助夥伴裁示最重要的,代辦的Task不是絕對、Story也隨時可以討論。」
再次提醒大家關於Scrum的精神,才不會在執行期間變成了聽命行事的機器。
※延伸閱讀>>【SCRUM工作術】文章總表
>>【Scrum規劃會議】(一)先說好目標與Story
>>【Scrum規劃會議】(二)說好Stroy的KPI與Criteria
>>【Scrum規劃會議】(三)進行Story Point的評分.如果你喜歡我的文章,歡迎給我拍拍手~「1下」拍手:到此一遊,留個記錄吧。
「5下」拍手:表示喜歡這篇文章。
「15下」拍手:表示你想要知道更多相關的內容!
「30下」拍手:手應該會有點痛,但還是歡迎繼續拍。按下「Follow」,追蹤我或我的專欄,將能定期收到優質的文章!