很簡單的 Story，也要拆分出 Tasks 嗎？

Scrum 已經夠精簡了，但很多人還是因為嫌麻煩、省時間，就省略原本預定該做的事情。

雖然在 2020 之前的 The Scrum Guide 並沒有規定 Sprint Planning 要分為 Part 1 & Part 2 ¹，但這可說是 Scrum 圈公認的最佳實踐。²

如果團隊已經成熟到能以自己的方式把 Sprint Planning 做好做滿，其實也未必非得硬性劃分 Part 1 & Part 2（畢竟 Scrum 推崇基於經驗主義的自組織、自管理）。最怕的是，不明白劃分 Part 1 & Part 2 的好處，不明白 Part 2 的重點及產出，甚至單純只因「嫌麻煩」、「省時間」，就省略原本預定該在 Part 2 進行的活動，往往會導致 sprint 進行途中出現種種問題。

很多問題，追根究柢，就是當初沒有認真進行 Part 2。

在 Part 2 中，有一個重要的步驟是將 Sprint Backlog Items 拆分出較小、較具體的 tasks ³ ——常被團隊輕看的步驟。我姑且不搬出專案管理的大道理 ⁴ ，純粹以 Scrum 日常經驗來反思「很簡單的 story，也要拆分出 tasks 嗎？」這個提問。

對自己：避免低估

工程師常會低估 story 所需耗費的時間資源。可能是刻意低估（迎合上意、打腫臉充胖子⋯⋯），也可能是不自覺的低估。前者當然不可取，後者雖然是無心之舉，但仍會造成 sprint fail 的風險，若無法道德勸說大家警覺，就得訴諸制度流程來避免。

將 story 拆分出較小、較具體的 tasks，其實就是切換至一個較為深入的視角來審視 story 的執行計畫。拆分出來的 tasks，不僅可當成 checklist 避免自己掛一漏萬，更可忠實反映 story 的複雜度——我常常看到團隊在真正嘗試將 story 拆分出好多張 tasks 便利貼之後，才回頭修改當初對於 story 的估點，而且往往是增加點數。

我很喜歡 Mike Cohn 大師在 User Stories Applied 所舉的 “Everything takes four hours” 例子：

In one episode the husband is being pestered by his wife to go shopping for a couch. She insists the trip will take only an hour. He tells her that “Everything in the world takes four hours. You gotta go there, you gotta do whatever, eat, talk about where you should have eaten, and then come home. That’s four hours minimum.”

This isn’t a bad rule of thumb for software development and is a perfect example of how projects get in trouble when they don’t distinguish between ideal time and elapsed time.

如果你堅持「這個 story 很簡單，根本不必浪費時間拆分出 tasks」，那麼，請想想 “Everything takes four hours” 這句話。

對團隊：製造流動感

讓 Daily Scrum 無趣的方法有很多，常見的病徵是：某一張卡片，日復一日就是一直停留在某一欄 (column)，沒有前進。

某Ａ問：「這張卡片，停留在這一欄好像已經好幾天了⋯⋯請問它怎麼了？」

答：「啊，就是還在進行中，還沒做完呀。」

某Ｂ問：「好幾天都一直停留在這裡，我怎麼知道它到底有沒有任何進展呀？」

答：「啊，就是還在進行中呀⋯⋯你懷疑我喔？」

團隊需要製造任務的流動感，以區隔「沒有流動的幻覺」與「真實的 blocker」兩種情況。

Scrum 的團隊未必會採用 Kanban 陣營的做法，但 Kanban 的 flow 觀念及視覺化手法很值得 Scrum 團隊借鏡。將 story 拆分出較小、較具體的 tasks，其實就是切換至一個較具流動感的視角來審視 story 的執行狀況。當你憑著每一天每一天 Daily Scrum 的視覺印象，懷疑某張 story 似乎停滯不前，或是憑著 burndown chart ⁵ 的量化資料，懷疑整個 sprint 似乎偏離理想斜線，那麼，在進入「blocker 問題解決模式」之前，請先試著檢查看看當初 tasks 拆分是否確實。

怎樣才能夠拆分出具有「流動感」的 tasks 呢？請參考我在〈工作分解講座‧閱讀材料〉文末的建議：

努力將 task 切到不超過 2 個工作天的程度。

當 Tasks 已經變成無趣的例行公事時

Ｃ問：「萬一我們每次將 story 拆分出來的 tasks 都長得一模一樣，還有必要浪費這些時間嗎？」

我：「請舉例。」

Ｃ：「就拿這一張 Story F 來說吧，我們會拆出這幾張 tasks：(1) Design Logic，(2) Design Schema，(3) Coding，(4) PR，(5) Deploy。」

Ｃ：「對其他那幾張 Story G、H、I 來說，其實也都是一樣的手順。每次都要同樣的複製貼上複製貼上，滿浪費青春的⋯⋯」

如果團隊面對的產品，真的如同這位Ｃ所說，在 tasks 層次的手順幾乎已經了無新意，那麼，在不犧牲前面講的「對自己：避免低估」及「對團隊：製造流動感」兩大好處的前提下，我會建議團隊：或許可試著將樸素的 Scrum task board 轉換成較精緻的 Kanban board，把例行手順變成 Kanban column。

「很簡單的 Story，也要拆分出 Tasks 嗎？」

你認為呢？