這篇文章將與您分享我們是如何調整，以及調整後發生哪些改變。

本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

大綱
ㄧ、調整的目的是什麼？
二、定義 Scrum Master 跟 PM 的權限
  ➤ Scrum Master
  ➤ PM
三、調整後發生哪些改變
  ➤ 成員對專案、團隊有更深刻的認知
  ➤ Scrum 參與度提升
  ➤ 回顧時發表更踴躍
四、總結

ㄧ、調整的目的是什麼？

明明跑的是 Scrum，卻沒有團隊合作的感覺。

每間公司跑 Scrum 的方式與目的不同，有些 Scrum 跑起來更像是傳統的工作匯報；即使在身處在同一個會議中，卻只有主管跟 PM 關心每個人的工作內容。

如果團隊成員不關心彼此的工作內容，單獨匯報或是用紙本報告其實更加省時；開 Scrum 的目的是希望大家了解彼此的任務，確認是否有需要調整的地方，避免任務的先後順序、優先度搞錯，導致專案進度延宕。

但如果只是口頭上說希望大家積極參與，實際效果就跟老師要學生好好聽課一樣，因此想透過流程來進行改善。

而我們選擇的方案是 — 讓團隊成員輪流擔任 Scrum Master。

二、定義 Scrum Master 跟 PM 的權限

我們希望在提升成員參與度的同時，盡可能不要增加負擔。

因為 Scrum Master 的工作內容與 PM 高度重疊，如果沒區分好彼此的界線，勢必會導致其他成員的困惑，比如：

1. 開單要找誰？
2. Sprint Planning 的規劃由誰負責？
3. 需求規格由誰來寫？

所以我們做了如下區分：

Scrum Master

1. 主持 Daily Scrum Meeting：了解每個人工作的進度、預計要做的事、以及遇到的問題。
2. 主持 Sprint Review、Retrospective 會議：讓大家報告在這個 Sprint 中做了什麼，有哪些好的可以繼續保持，有哪些壞的要進行調整。
3. 參與 Sprint Planning 會議：了解下個 Sprint 要完成的事項。

PM

1. 專案管理：追蹤成員的進度、討論需求、協調資源…原則上工作內容不變，只是部分工作交由 Scrum Master 主持。
2. 輔助 Scrum Master：儘管已經簡化許多 Scrum Master 的工作，但因為部分成員並沒有接觸過敏捷開發，因此需要幫忙拾漏補遺。
3. 規劃 Sprint Planning：無論是規劃要完成的工作，還是與每位工程師確認工時，都是需要花費不少心力的任務，因此主要還是由 PM 專職處理。

之所以這樣設計，是希望成員在擔任 Scrum Master 的同時，儘可能不影響到他的本職工作，我們期待這樣的流程可以讓每位成員更融入專案，而不是取代 PM 的工作。

三、調整後發生哪些改變

目前實行了 3 個 Sprint，成員的接受度還算高（希望不是敢怒不敢言 😅）。

成員對專案、團隊有更深刻的認知

不管是否願意，主持 Daily Scrum 時一定要了解每個人具體的狀況；原本專注在自己任務的人，也會因為主持 Sprint Review、Retrospective 而強迫了解整個專案，並更加認識團隊。

Scrum 參與度提升

因為 Scrum Master 是輪流的，如果我今天不給你面子好好聆聽跟報告，下次換我當 Scrum Master 時可能大家會不理我；同儕間的心理因素會讓參與度變得更高（但這個情形未必適用在每個團隊身上）。

回顧時發表更踴躍

由成員來做 Sprint Retrospective 時，大家相對來說更敢發表意見；這就跟同學分組討論時比較熱絡，但當老師問同學有沒有問題時，台下直接靜音的道理一樣。

四、總結

花的時間越多，就會越認真投入。

其實並不是每位成員在剛開始的時候都願意跑 Scrum 的，因為他們覺得這是在浪費時間、單純走一個形式、對專案沒有幫助…

因此初期更像是每天集合匯報工作，直到要輪流當 Scrum Master 時，因為無法拒絕，所以每位成員都一定要有所了解，而這個過程促使團隊往好的方向發展（應該 🤔）。

當然還要更多時間來驗證，相信每次的 Sprint Retrospective 都能讓原本的流程更加完善。

如果讀者有敏捷開發的經驗，歡迎留言分享，你的留言或許可以幫助到其他人。

工程師血淚史
▋ 團隊在系統開發上遇到了哪些問題
▋ 需求不斷變更，到底哪個環節出錯了
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？(本篇)
▋ 如果沒有明確的開發流程，團隊將會無所適從
▋ 你知道對專案來說，README.md 有多麼重要嗎？