【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」，追蹤我或我的專欄，將能定期收到優質的文章！
