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

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

大綱
ㄧ、調整的目的是什麼？
二、定義 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 有多麼重要嗎？

一、我們現在協作時遇到了哪些困境？
二、這個工具能給我們開發帶來什麼樣的幫助？
三、安裝套件＆登入使用者
四、使用方式

一、我們現在協作時遇到了哪些困境？

• 使用螢幕分享做 Debug 時，需要依靠大腦來做運算邏輯，想要看哪一支檔案與程式也要靠口述，非常不方便
• 有些程式（Teams），不只螢幕分享來能直接控制對方的電腦做操作，但同一時間只允許一人做操作
• 就算團隊使用 git 版控，你切到對方有 Bug 的 branch 時可能無法順利重現問題發生（很多套件版本及環境參數設定不同）
• 因為無法完全模擬對方程式運作環境導致 Debug 時困難重重

二、這個工具能給我們開發帶來什麼樣的幫助？

• 對方能夠很清楚理解自己現在講述的程式在哪個檔案的哪個位置，不再雞同鴨講
• 雙方能自由瀏覽專案下的資料夾與程式，無需依靠口述
• 可以模擬對方的環境進行程式編譯，更清楚問題發生點
• 雙方的游標顏色不同，方便討論時不會產生誤會

三、安裝套件＆登入使用者

下面的步驟及操作可能會隨著 VScode 改版而有所不同，僅供參考

SETP 1：在 VScode 的 EXTENSION 分頁搜尋「Live Share」，點擊「install」即可完成安裝

SETP 2：安裝完後會在左下角多出「LIVE SHARE」的icon

SETP 3：第一次按「Share」時，會要求你登入 GitHub 或是 Microsoft 的帳號

SETP 4：這裡我選擇登入Github，基本上就是一路按接受授權的過程

SETP 5：註冊成功後，你就會看到以下畫面

四、使用方式

完成安裝＆登入的步驟後，下面提供本機模擬的操作方式

自己跟自己的連線，模擬操作

SETP 1：在本機用 VScode 開啟一個資料夾或是專案

SETP 2：點擊「Share」做分享，此時你會得到一組邀請連結

SETP 3：此時開用「New Windows」開啟一個空的 VScode，點擊「Join」加入

SETP 4：加入後加入後便可以開始共同開發嚕

當 Join 的人對檔案操作時，Share 的人可以看到他的操作

了解 Share 的人跟 Join 的人正在操作的畫面

按下右上角的「圖釘」，就是「Follow Participant」觀看對方現在操作的檔案

直接在對方的環境下執行程式了解問題

Join的人可以直接在終端機下指令，了解程式執行狀況

本篇文章只是很簡略地讓大家了解如何使用「Live Share」這款套件，更多的功能就讓大家直接去官網了解吧！