緣起

我在〈One-Week Sprint 的節奏〉一文提到個人的「迷你版 Scrum」首航經驗：

第一個 sprint 順利達標，儘管變數層出不窮。

萬萬沒想到第一次嘗試帶 Scrum，而且是「1 舊人 + 2 新人」的高風險組合，就很有機會實現。除了天時地利人和的配合，事先認真的 WBS 分析，應是重要因素。

後來幾個 sprints，大體上也都順利達到 due-date performance。回顧經驗，我仍然認為「事先認真的 WBS 分析」是重要因素。

所以，當我想將成功經驗推廣到其他專案上面，有一個重要的前置作業，就是灌輸全員 decomposition 意識。

要以「WBS + activity」為單位，還是以「user story + task」為單位，我並沒有強制規定（也不是現階段的重點）。但其中的 decomposition 意識，則必須確實掌握。

因此，第一步，我先召集大家玩一次〈TOC 瓶頸處理九大原則〉，從樂高遊戲中學習；接下來的第二步，嗯，又是我「讀書會」招數派上用場的時機了。

讀書會的進行方式：

  • 活動前：各自閱讀指定材料。
  • 活動中：搭配 workshop 演練案例，而且是以公司真實的專案為實例，不僅具體，又能直接連結每個人的工作。

這種訓練是很重要的。畢竟，連自己經手過的專案都分解／拆解不出來了，還談什麼後續的 planning poker 呢？

真實專案 workshop 我打算分兩回合進行。以下僅列出可以公開釋出的閱讀材料，給大家參考。

Part I / 基本觀念

專業工作者，除了精進本職學能之外，我認為，還需要致力掌握適當的工作分解／拆解技能。

工作分解／拆解，並不只是專案經理的責任，而是實際執行者也必須參與的。這也是專業工作者的責任區。

這不是我個人的偏見，而是連 PMBOK 5/e 都如是說：

The project manager, in collaboration with the project team, then determines the final decomposition of the project scope into the discrete work packages that will be used to effectively manage the work of the project. (§5.4.2.2)

Each work package within the WBS is decomposed into the activities required to produce the work package deliverables. Involving team members in the decomposition can lead to better and more accurate results. (§6.2.2.1)

首先，請先讀讀以下這篇文章，初步了解 WBS (work breakdown structure; 工作分解結構) 的基本觀念：

有餘力的話，可再選讀：

小提醒：「工作分解結構」觀念，不管是古典的 PMP，還是近代流行的 agile、Scrum、Kanban，其實大原則是相通的。讀這幾篇文章時，請留意幾個重點：

  1. Deliverable (用名詞表述) 與 activity (用動詞片語表述) 的劃分。
  2. 逆向拆解。
  3. 100% Rule。
  4. 麥肯錫的 MECE 原則（Mutually Exclusive, Collectively Exhaustive），也就是說，WBS 拆解要做到「彼此獨立、毫無遺漏」。此處，「毫無遺漏」是首要重點。

Part II / 軟體界的工作分解

軟體研發領域，也需要工作分解：

請留意文章中這句話：“Our sprint length wasn’t the problem. Our ability to decompose work was.” 請思考背後的論述。

Part III / 好的 User Story 原則

INVEST 原則簡介

INVEST 原則細說 (by Bill Wake)

Part IV / User Story 拆解術

一般建議：

針對 workflow 的拆解建議：

Part V / 切到多細？

User story 及 task 要切到多細，並沒有標準答案。不過，我還是蒐集一下專家們給的建議。

Scrum 共同發明人 Ken Schwaber 在 Agile Software Development with Scrum 書中建議：

“Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish.”

Essential Scrum 第 19 章建議：

“Teams that take this approach typically follow a helpful rule of breaking down tasks so that no one task is more than eight hours of effort, although some might be a bit larger. At this level of granularity the team has a good idea of what really needs to be done and whether it can accomplish those tasks in the time it has available.”

The Scrum Field Guide 第 12 章則建議：

“Follow the rule that tasks should be completed in no more than two days.”

個人經驗是，努力將 task 切到不超過 2 個工作天的程度，能有效降低專案的不確定性及風險。

【敏捷的工作分解方法】系列

❶ One-Week Sprint 的節奏

❷ 工作分解講座・閱讀材料

❸ 事情做一半，等於沒完成：淺談敏捷的里程碑設定

❹ 以「蜘蛛法」拆分過於龐大的 User Story

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

❻ 變動的時代，為什麼工作分解技能更是必備？