前言
我們前一集提到，瀑布式專案管理的特點，由於瀑布式由上而下的方式可以很清楚的看出每個環節的內容，但因為時間較長也比較缺乏彈性。我們今天要講的敏捷式則是利用快速反應來彌補這樣的缺陷，也順便利用 Notion 官方預設的專案管理模版來說明，該如何套用在敏捷式專案管理。
SCRUM 敏捷式專案管理
如果說瀑布式的方法是由上往下的單向流動，那敏捷式比較像是由彈簧狀的螺旋組成來進行推移，事實上 SCRUM 本來就是設計給團隊操作而不是個人，其核心是一個自我發展的小組織、跨職能團隊，團隊有著特定的角色、事件，也必須遵循特定的步驟。
角色與定位
在 SCRUM 中，很強調每個成員間的角色和功能性，所有成員正常為 5～9 人（人數太少不夠客觀，太多意見容易分歧），每個角色如下：- 產品負責人（Product Owner）：負責確定產品需求、管理產品待辦清單，並與開發團隊合作完成產品，這個角色需要對產品有相當程度的瞭解，也需要跟利害關係人（Stakeholders）溝通並獲取對方的反饋再傳達給團隊。
- 敏捷大師（SCRUM Master）：負責指導團隊實踐 SCRUM 流程，消除障礙，促進團隊合作和協調，並專注在衝刺上，定位上是擔任引導者，也是領航員的角色。
- 開發團隊（Development Team）：負責設計、開發和測試產品，並與產品負責人和 SCRUM Master 合作完成產品，負責每次衝刺的測試和回饋，一般來說會由研究員、工程師或是設計師來編組執行。
SCRUM 內部團隊的成員組成，在 Notion 權限中，產品負責人為最高權限，而其他建議設定member（成員）等主要權限。
SCRUM 外部團隊成員，在 Notion 權限中，建議設定 guest（來賓）權限。
流程與階段（專有名詞）
當敏捷團隊角色明確後，接下來就是依照專案的目標，來規劃數次的 Sprint（衝刺），每次衝刺的理想週期為 10 天到兩週（最短不低於 7 天，最多不高於 30 天）。
- 建立產品待辦清單（product backlog）：由產品負責人跟開發團隊列出要完成的所有工作項目的列表，其中每個工作項目（Task）都源自一個用戶故事（user story）做為腳本。
- 所有成員表決每個工作項目的重要性，採用默認方式避免受到他人影響。
- 為達成共識可以使用費式數列（Fibonacci sequence），並統計成衝刺點（sprint point）。只要成員間的默認數字級距超過 3 級，或是有人投出 21 以上，代表認知差距過大，需重新投票。
1,2,3,5,8,13,21,34
- 依照最終的點數排出優先順序進行衝刺。
- 使用費式數列而非傳統數列的好處是：因為有累加的效果，在判斷的單位上比較統一，另一方面在衝刺點的統計結果，可以更好運用人力及分配資源，避免工作失衡的現象。
- 衝刺計畫（sprint planning）：由產品負責人跟開發團隊提煉成衝刺待辦清單（sprint backlog）。在 Sprint 計畫中，團隊從產品待辦清單中選擇一個工作項目，制定一個可行的計畫，並確定 Sprint 的目標和時間表，這裡開始就是衝刺的循環起點。
- 提出最小可行性產品（Minimum Viable Product），簡稱 MVP，能夠以最短時間交付給用戶體驗的內容，無論是產品或是服務。
- 衝刺計畫的目的：
- 定義衝刺的目標。
- 討論最優先的用戶故事。
- 將項目添加到即將到來的衝刺中。
- 每日站立會議（daily standup）：衝刺期間，每天全員進行 15 分鐘的會議，顧名思義採用站立開會的方式，一來有助於會議準時，二來確保大家的專注度集中。在會議中團隊成員報告他們：1.昨天完成的工作、2.今天將要完成的工作、3.遇到的問題和阻礙。該會議有助於團隊成員保持同步，以確保 Sprint 的成功。
- 每個人報告三項工作內容後，其他成員適時提供支援。
- 此階段應用白板或看板模式，將任務進度區分為待辦（To-do）、進行中（Doing）、已完成（Done）。
- 產品負責人要記錄大家回報的狀況和管制工作進度，而敏捷大師僅負責控管會議進行和衝刺的流程，所有成員彼此間沒有主導權。
- 衝刺檢視（sprint review）：依照利害關係人（stakeholder，主管、客戶、贊助商、出資者、供應商…等等）所提出的情報或用戶故事，經過跨部門團隊討論，再次精鍊成衝刺待辦清單。
- 此階段由產品負責人主持，由內部成員（研發團隊）及外部成員（利害關係人）共同參與，主要目的為修正現況及調整步伐，引導外部成員給予回饋。
- 此階段可以順便做成果展示，也就是展示 MVP 的內容，這裡最期待會有振臂疾呼的場景，對成員士氣都有很大提升。
- 再次運用費式數列和衝刺點，排出下次衝刺的優先順序，如果有新的用戶故事順便列入產品待辦清單。
- 衝刺回顧（sprint retrospective）：在衝刺結束後，團隊進行回顧，檢查衝刺期間的績效並確定改進措施。
- 由敏捷大師主導，這階段是要優化整個 SCRUM 的流程，同時也是團隊覆盤的時機。
- 哪些可改進、可優化，並列入下一次衝刺計畫。
- 重點放在敏捷式和衝刺流程的改善，大家一起集思廣益找出解決方案，提出每個人的自評貢獻度，開誠布公的討論有效無效的內容，而非批鬥大會。
- 可以參考燃盡圖（burn down chart），顯示剩餘工作量和時間關係的圖表，工作量應該隨著時間遞減，如果線條出現無變化（工作效率低），或是急遽下墜（加班所致），都不是正常的現象。
使用 SCRUM 來推進每一次的 Sprint（衝刺）
一次衝刺步驟是 2～5 為一個循環，可以依照實際情況設定衝刺的次數，衝刺週期要盡可能固定，Scrum 方法強調團隊合作、快速反應和自我管理。在實施 Scrum 時，需注意以下事項和重點：
- 清晰明確的產品待辦清單：用戶故事越具體越好（我是誰？我希望有某種功能，可以達到某種結果），當多個用戶故事可以發展成完整的 epics（用戶故事集）
- 短週期的迭代開發：一般大型專案無法容忍失敗，但是敏捷式希望更快找到失敗，更快做出調整。避免到最後才發現有問題，卻木已成舟無法回頭。
- 每日 Scrum 會議：強調神隊友，不要豬隊友（自動自發、積極負責、反應快速）
- 燃盡圖是一個參考，不要為了完美的線條而刻意執行，要按照正常的節奏才能發現問題。
還記得我們前一集有說過，敏捷式方法像是特別行動小組執行特殊任務的概念嗎？我們可以把每一次的攻堅視為一個 Sprint ，一般來說在 CQB（限制空間作戰）中，會有破門手、前鋒、小隊長、後衛等成員所組成，產品負責人就類似小隊長的角色，而每個房間可視為不同的 User Story（使用者故事），每次的主要任務就是解決用戶故事的問題。
敏捷團隊不是任何人都可以勝任，必須要有主動積極、善於溝通的特性，是萬中選一的優秀人才，反應要快也要信任彼此、開誠布公，大家是生命共同體，都是在同一條船上的決心，如果今天門的後面有三個歹徒，你只要專注負責其中一個目標，剩下兩個目標要相信隊友會幫你解決。
特性與結論
SCRUM 方法在軟體開發領域被廣泛應用，但也可以用於其他項目，例如市場營銷、產品開發、軟體開發、教育、政策擬定、防疫。有別於瀑布式方法會大量使用時間軸檢視，敏捷式方法則是用看板檢視。
優點
- 解決了傳統瀑布式方法的缺乏彈性，可以針對市場需求迅速做出因應。
- 流程透明且自主性高，可以帶來更多參與感，更精準達成目標也更能激發成員的工作潛能。
缺點
- 一開始需要花比較多時間讓大家知道自己的定位和功能，因為非常考驗默契，成員必須先瞭解角色的運作方式，認知要一致也需要專業引導。
- 需要全員參與並相互信任，如果成員不能主動積極，很可能失敗。
- 如果擔任敏捷大師的人不熟悉敏捷流程，就不能在團隊偏離時修正回來，也不能發揮敏捷式方法的效果。
在介紹完瀑布式和敏捷式專案管理，大家覺得「防疫」應該要採用哪種方式來執行會比較好呢？
