規模太大——最佳 Scrum 團隊規模指南

收聽本文的音頻版本

無論您是在小型初創公司工作還是在大公司開發新產品，您都可能會遇到一個團隊中有太多人的情況。 儘早識別跡象將使您免於進入團隊中效率最低的階段。

每個產品都是不同的，開發它們的團隊也是如此。 因此，拆分團隊還需要您做出一些反映您的情況的決定。 需要考慮的一些事項是：

• 當隊友不再一起工作時如何保持專業知識的完整性
• 您是否應該按職能劃分（例如，前端和後端團隊）？
• 新團隊是否應該有單獨的積壓工作？
• 產品管理團隊是否應該相應成長？

你應該什麼時候開始創建第二個團隊？

開始考慮團隊拆分或添加新團隊的最明顯跡像是您的預算增加時。 這可能發生在初創公司的新一輪投資或企業產品的新目標中。 如果預算增長如此之大，以至於您的團隊將增長 3 倍或更多，那麼您將不得不拆分當前團隊以分配專有技術，這是不言而喻的。 然而，當預算增加是漸進式的並且你最終在名冊中增加了一些新人時，這些決定就變得不那麼明確了。 例如，如果您計劃將您的團隊從 7 人增加到 11 人，那是否需要拆分？ 敏捷促進了小型團隊，但它也促進了個人和互動，而不是流程和工具。 擁有兩個或更多團隊不可避免地會創建更多能夠同步工作的流程。

專家怎麼說？

亞馬遜的創始人傑夫·貝佐斯（Jeff Bezos）一直在為會議和團隊使用兩個披薩規則。 這意味著每個人在午餐時應該只有兩個比薩餅可以餵飽的人數。

Scrum 指南建議讓 3 到 9 名團隊成員實際執行 sprint backlog。 這意味著您不會將產品所有者或 scrum master 包括在總數中，除非他們中的任何一個正在實施 sprint backlog 項目。

這些數字似乎很直觀，但背後也有一些數學原理。 如果你考慮一個團隊，每個人都像一個節點，他們連接到其他節點。 這些是隊友之間的人際關係。 他們可以是友好的、有競爭力的、惡意的或有愛心的。 無論兩個人之間的關係是什麼，它仍然是一個需要每個人都有一定心理能力的聯繫。 隨著團隊的發展，這些鏈接的數量不會線性增長。 節點之間鏈接的公式是 \(n(n-1)/2\)。 這是鏈接增長圖表：

該圖表從數學的角度清楚地說明了為什麼團隊在規模不大的情況下運作效率最高。 如果我們採用 Scrum 指南建議的 3 到 9 個團隊成員，我們最終會得到 3 到 36 個鏈接。 如果我們增長到 15 人，我們將擁有超過 100 個鏈接。 只有當他們的職責非常明確並且很少重疊或者如果有一些非官方的子組時，這樣的團隊才能有效地運作。 在基於敏捷原則工作時，既不是這種情況，也不是所希望的。

團隊變得太大的跡象

每日站會

有時被稱為每日站會，每日站會是整個團隊的聚會，討論衝刺的進展和障礙。 Scrum 指南建議將這些時間設置為 15 分鐘，這是對團隊規模的一個很好的試金石。 如果您開始注意到您的團隊超過了 15 分鐘欄，那麼它可能表明以下兩種情況之一：

• 每日站會效率不高。 人們正在進入太多細節。 或者沒有明確的發言順序，隊友發言需要時間。 也許產品負責人或 Scrum Master 正在利用每日 Scrum 作為提供與 sprint 無關的各種更新的機會。
• 團隊太大了。 如果每天的 Scrums 效率很高，但你仍然超過了 15 分鐘，那麼你可能只是團隊中的人太多了。 您還應該開始注意到人們正在失去興趣，因為一個人可以接收多少信息是有限的。如果提供更新的人太多，就很難跟踪每個人的進度並了解團隊的狀態. 這使人們轉向內心，只反思自己的進步，而不是尋找幫助他人的機會。

梳理和衝刺計劃

梳理和衝刺計劃都是與分解用戶故事和估計其交付時間或規模相關的活動。 雖然擁有更多人可以幫助團隊做出更好的決策，但擁有太多人可能會使團隊陷入僵局。 總是有不同的方法來完成相同的任務，並且每一方的爭論的數量隨著團隊中的人數而增加。

與每日 Scrum 一樣，不要將低效的計劃會議與團隊規模過大混為一談。 歸根結底，讓 Scrum 儀式變得高效和有效是 Scrum Master 的工作。

回顧展

在回顧期間，團隊成員可以解決任何爭論或衝突，並提出改進工作流程的方法。 回顧會教會我們妥協的藝術，因為它讓我們在各方之間尋求共同點。 一個團隊的強大在於其成員願意在分歧上妥協。

然而，與 sprint 計劃一樣，太多的團隊成員創建了太多的鏈接，所有這些都是潛在的衝突點。 開始注意你是否在回顧過程中發現越來越少的共同點。 這可能表明團隊太大並且會從拆分中受益。

如何拆分團隊

從表面上看，拆分團隊是一項相對容易的任務。 將團隊成員分成兩組，確保每個人都有類似的經驗，並為新團隊定義目標。 但是，有很多事情需要考慮，這可能會對新團隊未來的成功產生重大影響。

團隊士氣

可能要記住的最重要的事情之一是團隊士氣。 歸根結底，團隊中的人將不得不在新的組合中工作。 如果團隊在敏捷原則方面成熟，那麼他們應該能夠自己進行拆分。 這是最理想的結果，因為團隊成員最了解他們的內部關係——誰與誰合作得最好，誰可以從單獨的團隊中受益。

跨職能團隊

Scrum 提倡跨職能團隊“具備創建產品增量所需的所有技能”。 這適用於擴展到兩個或更多團隊時。 對於很多開發人員來說，尤其是如果他們是敏捷新手，自然傾向於沿著技術路線思考。 例如，團隊通常希望拆分為後端團隊和前端團隊。 這在極少數情況下可能是有意義的，但作為產品經理，您應該在大多數情況下建議不要這樣做。 一個由前端人員組成的團隊無法自行交付產品增量，自然會開始更多地考慮技術能力，這是他們團結起來的原因。 相反，他們應該關注客戶以及如何滿足他們的需求。

另一個有趣的考慮是團隊中的非開發角色。 在各種情況下，團隊可能包括設計師、業務分析師或 QA 專家。 一旦你拆分了一個團隊，特別是如果你沒有僱傭太多新人，那麼如何處理這些角色就會出現兩難境地。 他們應該在團隊之間分配時間嗎？ 你是否應該僱傭新的人，他們只專注於一個團隊？ 他們應該與開發團隊合作還是成為產品團隊的一員？

對此確實沒有好的單一建議，因為每種產品都如此不同。 這些決定最好與團隊一起做出，請記住，您可能需要在此過程中糾正路線。

團隊應該有單獨的積壓工作嗎？

如果一個團隊被拆分，那麼很自然的問題是他們應該處理相同的待辦事項還是有單獨的待辦事項。 我們可以從 Scaled Agile Framework 中獲得指導。

Scrum@Scale

Scrum@Scale 是由 Scrum 指南的創建者開發的一種方法。 Scrum@Scale 不是很規範，也沒有具體概述如何處理產品積壓。 但是，它確實注意到了兩點：

• 團隊級別的流程與 Scrum 指南中的規定相同。
• 產品負責人組成一個產品負責人團隊，他們在其中創建一個統一的積壓工作。 這樣做是為了避免重複工作並在公司內部創建可見性。 同時，團隊有他們單獨的待辦事項，這些待辦事項從統一的待辦事項中提供項目。

所以本質上，Scrum@Scale 用他們各自的 PO 和 backlog 來描繪新團隊。 它只是添加了一些額外的結構來協調團隊之間的工作。 Scrum@Scale 最適用於幾個、幾十個或數百個團隊，但即使您與兩個團隊一起工作，它也可以提供一些有價值的見解。

大規模 Scrum (LeSS)

LeSS 提倡一種有趣的方法來處理產品 backlog。 在 LeSS 中，產品負責人與兩到八個團隊一起工作。 一個 PO 似乎不可能與這麼多團隊合作。 LeSS 理念是 PO 在抽象級別上工作，並將產品待辦事項項細化職責委託給團隊。 在這種情況下，跨職能開發團隊還應該包括業務領域知識，以便能夠交付產品增量。 在 LeSS 中，只有一個 backlog。

如何保持最新

對於產品經理來說，多個團隊意味著更多的工作來跟踪進度和響應查詢。

優先安排會議

如果你參加的是單個團隊的每日例會，繼續這種習慣很可能是徒勞的。 將每日例會視為一個了解團隊脈搏並提醒他們您可以參與討論的機會。

您是否參加 sprint 計劃會議將取決於團隊的成熟度。 如果團隊中有很多新面孔，或者他們很長時間沒有使用敏捷，那麼您的一些指導將是必要的。 即使您有信心讓團隊在您不出席的情況下進行計劃，如果出現任何問題，請確保在他們的計劃期間可以隨時加入或與團隊進行語音聊天。

Sprint 評審必須始終是您的首要任務，所有評審都應參加。 Sprint 審查是一個從任何當前利益相關者和團隊本身獲得第一手反饋的機會。 這是驗證假設的時候，不應錯過。

與 Scrum Master 進行更多互動

雖然您可能會減少對某些 Scrum 儀式的參與，但您應該加倍加強與 Scrum Master 的合作。 團隊分裂後現在可能不止一個，在這種情況下，您需要與他們所有人密切合作。

確保您可以信任他們對團隊的進展和衝刺期間出現的任何問題給出誠實的看法。 這些關係將使您無需參加所有的 Scrum 儀式就能保持最新狀態。

介紹 Scrum 的 Scrum

有時稱為元 scrum，scrum of scrums 是一種新的儀式，通常作為 scrum 過程規模引入。 它是更高級別的每日 Scrum 的複製品。 每個團隊指定一名大使，所有這些大使每天都在 scrum of scrums 中開會討論進展和障礙。 該儀式還用於強調任何可能需要解決的跨團隊技術問題。

考慮擴大產品團隊

如果您的 Scrum 設置需要產品經理積極參與團隊，請考慮在產品方面增加更多人員。 有幾種方法可以解決這個問題。

初級產品經理。 一種途徑是為自己承擔更具戰略意義的角色，同時增加初級產品經理來處理一些日常瑣事。 他們可以承擔一些任務，例如質量保證 (QA)、為用戶故事編寫規範或為新功能創建高級模型。

業務分析師。 另一種方法是讓一個或多個業務分析師在團隊中或與團隊一起工作。 產品經理可以與業務分析師一起確定產品假設，然後讓業務分析師通過研究或新功能找到驗證它們的方法。

結論

隨著團隊的壯大，您可能會開始注意到一些跡象表明它變得太大，尤其是在：

• 每日站會。 如果您在每日例會期間超過了 15 分鐘的時間範圍，並且看到人們開始失去興趣。
• 衝刺計劃。 如果您在 sprint 計劃中越來越頻繁地陷入僵局。
• 回顧展。 如果你開始注意到在回顧過程中達成妥協變得越來越難。

所有這些都表明您可能需要拆分團隊。 拆分團隊似乎是一件容易的事，但它也會產生持久的後果，每個產品經理在這樣做時都有一些事情需要考慮：

• 團隊士氣。 理想情況下，您應該讓團隊決定他們希望如何拆分，以盡量減少廢棄的良好工作關係的數量。
• 跨職能團隊。 團隊應該具備創建產品增量所需的所有技能。
• 產品積壓。 確定您的團隊是否有單獨的或單一的統一積壓工作。

跟踪兩個或更多團隊將需要您確定優先級。 一個有效的產品經理應該計劃他們將如何與新團隊保持同步：

• 優先安排會議。 想想哪些敏捷儀式值得你花時間，哪些可以忽略。
• 與 Scrum 大師互動。 使用 scrum master 作為您的團隊代理並從他們那裡收集信息。
• 擴大產品團隊。 添加人員與您一起工作，並幫助您完成日常重複性任務或進行用戶研究和市場分析。

通過利用這些建議，您應該能夠進行乾淨的團隊拆分。 如果您的團隊不斷壯大，並且您將來會增加更多團隊，您應該閱讀 Scaled Agile Framework，它為大規模敏捷提供結構和流程建議。