Notion 一點通|SCRUM 敏捷式專案管理 #Sprint 的正確用法

前言

我們前一集提到,瀑布式專案管理的特點,由於瀑布式由上而下的方式可以很清楚的看出每個環節的內容,但因為時間較長也比較缺乏彈性。我們今天要講的敏捷式則是利用快速反應來彌補這樣的缺陷,也順便利用 Notion 官方預設的專案管理模版來說明,該如何套用在敏捷式專案管理。

SCRUM 敏捷式專案管理

如果說瀑布式的方法是由上往下的單向流動,那敏捷式比較像是由彈簧狀的螺旋組成來進行推移,事實上 SCRUM 本來就是設計給團隊操作而不是個人,其核心是一個自我發展的小組織、跨職能團隊,團隊有著特定的角色、事件,也必須遵循特定的步驟。

角色與定位

在 SCRUM 中,很強調每個成員間的角色和功能性,所有成員正常為 5~9 人(人數太少不夠客觀,太多意見容易分歧),每個角色如下:

  1. 產品負責人(Product Owner):負責確定產品需求、管理產品待辦清單,並與開發團隊合作完成產品,這個角色需要對產品有相當程度的瞭解,也需要跟利害關係人(Stakeholders)溝通並獲取對方的反饋再傳達給團隊。
  2. 敏捷大師(SCRUM Master):負責指導團隊實踐 SCRUM 流程,消除障礙,促進團隊合作和協調,並專注在衝刺上,定位上是擔任引導者,也是領航員的角色。
  3. 開發團隊(Development Team):負責設計、開發和測試產品,並與產品負責人和 SCRUM Master 合作完成產品,負責每次衝刺的測試和回饋,一般來說會由研究員、工程師或是設計師來編組執行。
內部團隊

SCRUM 內部團隊的成員組成,在 Notion 權限中,產品負責人為最高權限,而其他建議設定member(成員)等主要權限。

外部團隊

SCRUM 外部團隊成員,在 Notion 權限中,建議設定 guest(來賓)權限。

流程與階段(專有名詞)

當敏捷團隊角色明確後,接下來就是依照專案的目標,來規劃數次的 Sprint(衝刺),每次衝刺的理想週期為 10 天到兩週(最短不低於 7 天,最多不高於 30 天)。

  1. 建立產品待辦清單(product backlog):由產品負責人跟開發團隊列出要完成的所有工作項目的列表,其中每個工作項目(Task)都源自一個用戶故事(user story)做為腳本。
    1. 所有成員表決每個工作項目的重要性,採用默認方式避免受到他人影響。
    2. 為達成共識可以使用費式數列(Fibonacci sequence),並統計成衝刺點(sprint point)。只要成員間的默認數字級距超過 3 級,或是有人投出 21 以上,代表認知差距過大,需重新投票。1,2,3,5,8,13,21,34
    3. 依照最終的點數排出優先順序進行衝刺。
    4. 使用費式數列而非傳統數列的好處是:因為有累加的效果,在判斷的單位上比較統一,另一方面在衝刺點的統計結果,可以更好運用人力及分配資源,避免工作失衡的現象。
  2. 衝刺計畫(sprint planning):由產品負責人跟開發團隊提煉成衝刺待辦清單(sprint backlog)。在 Sprint 計畫中,團隊從產品待辦清單中選擇一個工作項目,制定一個可行的計畫,並確定 Sprint 的目標和時間表,這裡開始就是衝刺的循環起點。
    1. 提出最小可行性產品(Minimum Viable Product),簡稱 MVP,能夠以最短時間交付給用戶體驗的內容,無論是產品或是服務。
    2. 衝刺計畫的目的:
    3. 定義衝刺的目標。
      • 討論最優先的用戶故事。
      • 將項目添加到即將到來的衝刺中。
  3. 每日站立會議(daily standup):衝刺期間,每天全員進行 15 分鐘的會議,顧名思義採用站立開會的方式,一來有助於會議準時,二來確保大家的專注度集中。在會議中團隊成員報告他們:1.昨天完成的工作、2.今天將要完成的工作、3.遇到的問題和阻礙。該會議有助於團隊成員保持同步,以確保 Sprint 的成功。
    1. 每個人報告三項工作內容後,其他成員適時提供支援。
    2. 此階段應用白板或看板模式,將任務進度區分為待辦(To-do)、進行中(Doing)、已完成(Done)。
    3. 產品負責人要記錄大家回報的狀況和管制工作進度,而敏捷大師僅負責控管會議進行和衝刺的流程,所有成員彼此間沒有主導權。
  4. 衝刺檢視(sprint review):依照利害關係人(stakeholder,主管、客戶、贊助商、出資者、供應商…等等)所提出的情報或用戶故事,經過跨部門團隊討論,再次精鍊成衝刺待辦清單
    1. 此階段由產品負責人主持,由內部成員(研發團隊)及外部成員(利害關係人)共同參與,主要目的為修正現況及調整步伐,引導外部成員給予回饋。
    2. 此階段可以順便做成果展示,也就是展示 MVP 的內容,這裡最期待會有振臂疾呼的場景,對成員士氣都有很大提升。
    3. 再次運用費式數列和衝刺點,排出下次衝刺的優先順序,如果有新的用戶故事順便列入產品待辦清單。
  5. 衝刺回顧(sprint retrospective):在衝刺結束後,團隊進行回顧,檢查衝刺期間的績效並確定改進措施。
    1. 由敏捷大師主導,這階段是要優化整個 SCRUM 的流程,同時也是團隊覆盤的時機。
    2. 哪些可改進、可優化,並列入下一次衝刺計畫。
    3. 重點放在敏捷式和衝刺流程的改善,大家一起集思廣益找出解決方案,提出每個人的自評貢獻度,開誠布公的討論有效無效的內容,而非批鬥大會。
    4. 可以參考燃盡圖(burn down chart),顯示剩餘工作量和時間關係的圖表,工作量應該隨著時間遞減,如果線條出現無變化(工作效率低),或是急遽下墜(加班所致),都不是正常的現象。
敏捷式專案管理

使用 SCRUM 來推進每一次的 Sprint(衝刺)

一次衝刺步驟是 2~5 為一個循環,可以依照實際情況設定衝刺的次數,衝刺週期要盡可能固定,Scrum 方法強調團隊合作、快速反應和自我管理。在實施 Scrum 時,需注意以下事項和重點:

  1. 清晰明確的產品待辦清單:用戶故事越具體越好(我是誰?我希望有某種功能,可以達到某種結果),當多個用戶故事可以發展成完整的 epics(用戶故事集)
  2. 短週期的迭代開發:一般大型專案無法容忍失敗,但是敏捷式希望更快找到失敗,更快做出調整。避免到最後才發現有問題,卻木已成舟無法回頭。
  3. 每日 Scrum 會議:強調神隊友,不要豬隊友(自動自發、積極負責、反應快速)
  4. 燃盡圖是一個參考,不要為了完美的線條而刻意執行,要按照正常的節奏才能發現問題。

還記得我們前一集有說過,敏捷式方法像是特別行動小組執行特殊任務的概念嗎?我們可以把每一次的攻堅視為一個 Sprint ,一般來說在 CQB(限制空間作戰)中,會有破門手、前鋒、小隊長、後衛等成員所組成,產品負責人就類似小隊長的角色,而每個房間可視為不同的 User Story(使用者故事),每次的主要任務就是解決用戶故事的問題。

敏捷團隊不是任何人都可以勝任,必須要有主動積極、善於溝通的特性,是萬中選一的優秀人才,反應要快也要信任彼此、開誠布公,大家是生命共同體,都是在同一條船上的決心,如果今天門的後面有三個歹徒,你只要專注負責其中一個目標,剩下兩個目標要相信隊友會幫你解決。

特性與結論

SCRUM 方法在軟體開發領域被廣泛應用,但也可以用於其他項目,例如市場營銷、產品開發、軟體開發、教育、政策擬定、防疫。有別於瀑布式方法會大量使用時間軸檢視,敏捷式方法則是用看板檢視。

優點

  1. 解決了傳統瀑布式方法的缺乏彈性,可以針對市場需求迅速做出因應。
  2. 流程透明且自主性高,可以帶來更多參與感,更精準達成目標也更能激發成員的工作潛能。

缺點

  1. 一開始需要花比較多時間讓大家知道自己的定位和功能,因為非常考驗默契,成員必須先瞭解角色的運作方式,認知要一致也需要專業引導。
  2. 需要全員參與並相互信任,如果成員不能主動積極,很可能失敗。
  3. 如果擔任敏捷大師的人不熟悉敏捷流程,就不能在團隊偏離時修正回來,也不能發揮敏捷式方法的效果。

在介紹完瀑布式和敏捷式專案管理,大家覺得「防疫」應該要採用哪種方式來執行會比較好呢?

分享本文


阿哲|大腦整理師
阿哲|大腦整理師

我是阿哲,我是一名兼職的整理師,喜歡研究各種提升生產力的方法和工具,目前正在推廣#數位收納的路上…

文章: 39

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *