明天是 Rson 這個 Sprint Review 的日子，那麼，今天就來盤點回答一些朋友私訊過來的問題吧！

Scrum 開發團隊的人數愈多愈好。。。嗎？

昨天有朋友問到，開發團隊的人數多少才適合呢？就如軟體專案管理經典－人月神話 這本書所提到的觀念，軟體開發中，人力和時間並不呈現線性關係，隨著人數增加，在溝通、資源分配、及交際的成本會開始成等比級數上升，除了降低個人和團隊的生產力外，也有可能會產生 責任分散效應。透過適當的人數限制，反而能夠控制時間成本，以及避免「溝通癱瘓」和不必要的會議，更能專注在開發上。

我們可參考敏捷大神們普遍的建議， 5-9人（7 加減 2 ）最適當；也可以斟酌 Amazon 「不超過二個披薩可餵飽」的人數原則。

話說現在大半夜的實在好餓，寫到這裡突然好想來片芝心披薩… (離題了快回來！！)

Scrum 框中常聽到的名詞－Stakeholder

<Scrum 角色介紹> 一文中所說明的三種角色，是 Scrum 裡做事的人，一個專案當然不可能只存在這三種人，其他與專案／產品相關，但沒有實際參與的角色，統稱為利害關係人 （Stakeholder），例如客戶、使用者、單位主管、外部顧問等。一般而言 Stakeholder 只能觀察並給予意見，不該也不能干擾開發過程及決策。當然，這是 Scrum 的理想，實際運行上幾乎不可能。

傳統專案管理中，有提到利害關係人管理可採取的策略：先依二維度分類關係人，再依所在象限的策略進行管理，如下圖所示：

乍看之下是不是很威很有道理？不過，Rson 曾在幾個不同類型的案子中實踐過這個方式，始終覺得心累 效果並沒有那麼理想。與其管理利害關係人，倒不如適時邀請他們參與團隊的關鍵活動（例如 Sprint Review/Plan Meeting 等都是很好的時機），但得事先派個勇者（一般來說會是 PO 或是 Scrum Master），想辦法先與關係人們溝通好一個決策議事原則，才不會到時會議上多個關係人意見你一句我一句，多頭馬車互相拉扯，導致 Scrum 團隊不知道該聽誰的才好。