【Scrum規劃會議】(四)如何撰寫工作計畫，並總結規劃
開發團隊最重要的任務「撰寫Task」，也就是列出自己的「待辦清單」，讓團隊更好地完成任務。
為什麼要寫這篇文章?為了確保衝刺期的執行順暢度，並更好地評估是否能完成工作，規劃會議的最後一步，會需要制定工作計畫。讀完這篇文章後，你可以瞭解什麼？1.工作計畫的精隨所在
2.如何做最後的檢視
3.規劃會議的結論要包含什麼
工作計畫的基本概念
工作計畫的撰寫，會由實際執行的開發團隊來討論，過往經驗大概都會花2~3小時來進行。
簡單來說就是「拆解工作步驟」，把 User Story 拆解成小於等於一天的工作單位，最多大概是一個 6 小時的工作量，我把這個單位定義為Task，並且除了單純的拆解，也可以加上，誰來做、做的時間多久。
換句話說，「當把這些Task完成後，就可以完成User Story了」
如何寫出真實的工作計畫 ?
對於從來沒有詳細列出工作計畫的人，在寫Task時一定會有些困擾，可以想想看你會如何寫這個項目的工作計畫？
「把大象放進冰箱裡，要怎麼做？」
第一次寫有，有些人會寫：
Task 1-「把大象放進冰箱」
但這樣會跟沒寫差不多，並沒有真的把Story拆解成更小的單位。需要做的是，加入更多的「動作」與「細節」：
Task 1-「把冰箱的門打開」
Task 2-「把大象放進冰箱」
Task 3-「把冰箱的門關上」
簡單來說，就是寫完的Task要感覺它會動一樣，以我的經驗，只要分數超過5分，Task如果寫不到5個，時間通常會比預期想得還多。
寫出動態感還有另一個好處，就是當工作足夠小、足夠明確，團隊就有互助的可能。因為他人可以很清楚知道，現在這個工作在哪個狀態，事後檢討時，也可以辨認出究竟是哪一個細節，使得Story遲遲無法完成。
但也需要考慮一點，就是當我們過度在意細節時，整個任務執行的彈性就可能降低，會讓人覺得「必須」這樣做，而不是以「目標導向」的方式來工作。
親自撰寫，反映實際執行狀況
如果有些工作項目，已選定由某人執行，建議就該由他來決定Task的內容，換句話說，不要幫人寫Task。
畢竟，完成任務有各式各樣的方法，每個人適合、擅長的方式也不同，幫其他人寫，甚至可能會讓人不知所云，為了避免影響到執行的彈性與順暢度，由執行者親自撰寫才是較好的選擇。
安排順序，時間點
由於整個衝刺期，會有多件事要做，為了更有效率地協作，需要把一些時間點和順序寫出來。
例如：
第一周：開始 Story A→B→C
第二周：開始 Story D→E→F
第三周：完成 A、B、D、E
第四周：完成 C、F
也可以使用甘特圖來進行排序，主因是每個工序之間，多少都需要等待他人完成，才能做下一步，善用等待期間，不僅讓單個Story能順利完成，也讓多個Story在交錯的工序中更有效率。
三個問題，進行最後檢驗
當把 Task 寫完之後，可以運用三個問題，重新檢視行動計畫是否足夠好。
1. 為什麼這樣做，可以完成User Story？
這個問題，用於檢視Story與Task的關係，前面有提到Task大原則是「做完之後，就意味著User Story」完成了。
重新檢視Story與Task的關係，可以幫助我們查看是否有漏掉一些重要步驟，或是順序不佳導致影響產出品質的可能。
2. 為什麼這樣做，與衝刺目標一致？
有個很特別的情況，就是即便我們擁有目標，對未來有一個美好的想像，但真正在撰寫工作計畫時，有一些落差會被凸顯出來。
可能源自於技術落差、工作時間的評估落差，如：技術上不可行、這件事好像沒有價值、花費時間比預期多太多、目前產品程式架構難以配合。
畢竟，在沒有真正想每一步該怎麼做以前，很難判斷易一些細節。因此，即便我們能完成單項的User Story，也可能在思考工作計畫時發現一些盲點。
3. 有沒有更快、更省、效果更好的方式？
前面有提到，為了讓目標有效率地達成，我們應該保持計畫的彈性，為了主動利用這個彈性，可以在撰寫工作計畫的任何時刻，詢問類似的問題：
- 「有沒有更省力的方式？」
- 「為什麼會想用這個方法？」
- 「有沒有一些創新的做法？」
大家透過腦力激盪、彼此提醒，更能在過程中保持靈敏的思緒。
宣布衝刺清單（Sprint Backlog）
在一個10人以下、一個月衝刺期的Scrum團隊，規劃會議應該要在8小時內完成，在這之後，我們也來到了規劃會議的終點，宣布、回答一開始的三個問題，也就是本次衝刺期後
- 將帶來什麼樣的價值
也就是短、中、長期的目標，並著重本次的衝刺目標（Sprint Goal） - 將完成哪些產品代辦清單（Product Backlog）的項目
也就是預計會「完成」的User Story。 - 將會如何協作完成
也就是Story、Task的工作時間、時間點、順序關係。
如此，就完成整個規劃會議了！
接下來就是開始執行任務，並在衝刺期間進行每日的會議！
