無論你在小型創業公司工作還是在大公司的新產品線工作，當團隊人數越來越多時總會達到一個臨界點。儘早識別這個臨界點可以讓您的團隊避免進入低效階段。
每個產品都是不同的，團隊合作也是如此。因此，拆分團隊也需要做一些反映團隊情況的決定。在做決定時有以下幾點需要考慮：

• 團隊不在一起工作時如何確保專業知識的完整性？
• 是否應該按職能劃分？（如：前端團隊和後端團隊）
• 新的團隊應該有單獨的backlog嗎？
• 產品管理團隊是否應該相應增長？

什麼時候開始建立第二個團隊？

開始考慮團隊拆分或增加新團隊最明顯的跡象就是團隊的預算增加。這可能發生在創業公司的新一輪投資或企業產品的新目標中。如果預算增加較多你的團隊規模會增長3倍甚至更多，這個時候你就不得不拆分現有的團隊以延續原有的技術知識。然而，當預算增加呈遞增式時，你的決定就變得沒有那麼明確，最終的結果就是在名冊上增加一些新人。如果說，你計劃將自己的團隊由7個人增加到11個人，需要做拆分嗎？敏捷提倡小團隊，但也同樣提倡個體和互動高於流程和工具。擁有兩個或以上的團隊必可避免的要建立更多流程以便能夠同步工作。

專家怎麼說？

亞馬遜創始人貝索斯曾將兩個披薩原則用在會議和團隊中。那就意味著無論是會議還是團隊應該只有兩個披薩可以餵飽午餐的人數。
Scrum指南建議有3到9名成員實際執行sprint backlog。這就意味著總數中不可能包含PO或者Scrum Master，除非他們他們當中有人在執行sprint backlog項。
這些數字看起來更有直觀意義，但他們背後也有數學原理。如果將團隊中的每個人都看做一個節點，並將他們連結到其他節點。這就是隊友之間的人際關係。他們之間可以是友好的、競爭的、惡意的或者關懷的。無論兩人之間的關係是什麼，都需要每個人有一定的心理承受能力。隨著團隊人數的增長，這些連結之間的數字不會呈線性增長。節點之間的連結公式，如下圖的連結增長圖所示：

圖表從數學角度清楚的說明了為什麼當團隊規模不是特別大的時候能實現運營效率的最大化。如果我們遵從Scrum指南的建議採用3到9人的團隊規模人數，最終的連結值為3到36.如果把團隊人數增加到15人，連結值將超過100。這種規模的團隊只有在團隊中每個人的責任定義都非常明確且很少重疊或者一些非官方的小組才能有效運營。基於敏捷原則工作時既非案例也非期望。

團隊變大的訊號

每日Scrum

每日Scrum是整個團隊的聚會，用於闡述sprint進展和遇到的困難，有時候也被稱為每日站會。Scrum指南建議每日站會要在15分鐘內完成，這個時間限制對團隊規模來說是很好的試金石。如果你注意到自己的團隊開始超過15分鐘線，那麼可以表明兩件事：

• 站會效率較低。大家陷入太多細節當中。或者沒有明確的發言順序需要團隊成員輪流點名。也有可能PO或Scrum Mater利用站會時間提出與sprint無關的各種更新。

• 團隊規模過大。如果站會效率很高，但是你的團隊開會時間仍然超過15分鐘，那就很有可能是你的團隊人數過多導致的。你還應該注意到團隊中的一些人正在逐漸失去興趣因為一個人可以接收的資訊量是有限制的。如果太多人提供更新，那麼跟蹤每個人的進度並瞭解團隊的狀態就會變得很難。這使得人們只會向內看，只看到自己的進步而不是尋找機會去幫助他人。

梳理和Sprint規劃

梳理和迭代規劃都是與分解使用者故事和預估交付時間或規模大小有關的活動。雖然有更多的人可以幫團隊做出更好的決策，同樣的擁有太多人也容易讓團隊陷入僵局。同一任務可以由不同的方法來完成，並且每一邊的論點數量都會隨著人員數量的增加而增加。
與站會一樣，不要把低效的計劃談話與團隊規模過大混淆。最終，讓scrum儀式變得更高效且有效是scrum master的工作。

回顧

在回顧會議期間，團隊成員可以解決任何爭論或衝突並提出改善其工作流程的方法。回顧會議教會我們妥協的藝術，因為它讓我們在不同團體直接尋求共同點。團隊也因為它的成員願意在他們的分歧上適當妥協而變得強大。
然而，和sprint規劃一樣，團隊成員過多那麼連結點也會很多，所有這些連結點都是潛在衝突。如果你在回顧會議時發現大家的共同點越來越少的時候你就應該開始注意。這很有可能是由於團隊規模過大，團隊拆分是最佳選擇。

如何拆分團隊？

表明上看，拆分團隊是一個相對簡單的任務。將團隊成員分成兩組，確保每組中都有相似經歷的成員，明確新團隊的目標。然而，在拆分團隊時還有很多因素需要考慮進去以免影響團隊以後的成功。

團隊士氣

需要時刻牢記的最重要的事情之一就是團隊士氣。一天結束時，團隊中的成員將不得不在新的組織架構中工作。如果團隊在敏捷原則方面是成熟的，那麼他們應該能夠自己分裂。這是最理想的結果，因為團隊成員最瞭解他們的內部關係——誰與誰關係最好以及誰能從分離的組織中收益。

跨職能團隊

Scrum推動跨職能團隊“擁有建立產品增量所需的所有技能”。擴充套件到兩個甚至更多團隊時也是如此。對於很多開發者尤其是一些敏捷新手來說，自然趨勢是與技術線路一起思考的。例如，團隊經常想將拆分成前端和後端。這在某些罕見的情況下可能會有意義，但作為產品經理，你應該在大多數時間提出反對意見。一個全是前端開發者的團隊無法自行提供產品增量並且自然地就開始思考技術能力也就是將他們團結起來的原因。相反，他們更應該關注的是客戶以及如何滿足他們的需求。
另一個有趣的考慮因素是團隊中的非開發角色。在各種情況下，一個團隊可能包括一個設計師、業務分析師和QA專家。一旦你拆分了一個團隊，尤其是如果你沒有僱更多的新人，那麼在處理這些角色的問題上就會陷入兩難的境地。他們應該分配自己的時間到不同的團隊嗎？你應該僱傭只服務於一個團隊的新人嗎？他們應該跟開發團隊一起工作呢還是成為產品團隊的一員？
對此並沒有絕對的好建議因為每個產品都是不同的。這些決定最好與團隊一起做出，同時記得需要一直不斷修正。

團隊之間應該有獨立的Backlog嗎？

如果一個團隊被拆分，那麼接下來的問題自然就是他們應該用同一個backlog工作還是再獨立一個backlog出來。
Scrum@Scale是由Scrum指南的建立者開發的一種方法。Scrum@Scale不是很規範，但它確實指出了兩點：

• 團隊級別的流程跟Scrum指南中的流程相同。
• 產品負責人組成專門的產品負責人團隊，在他們那裡建立單一的backlog。這樣做是為了避免重複工作，在公司範圍內增強可見性。與此同時，團隊從統一的backlog中提取各自的backlog。

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

大規模scrum（LeSS）

LeSS提供了一種有趣的產品backlog方法。在LeSS中，一個PO與2到8個團隊一起工作。一個PO能跟那麼多團隊一起工作看起來有點不太可能。LeSS的理念是PO在抽象層面上工作，並將產品backlog項細化的職責委託給團隊。這種情況下，跨職能開發團隊還應該包括業務領域知識以便交付產品增量。在LeSS中，只有一個backlog。

如何保持更新？

對於一個產品經理來說，多團隊意味著更多的工作追蹤和響應查詢。

優先順序會議

如果你曾參加單個團隊的每日站會，那麼現在你可能會發現繼續這個習慣很可能是徒勞的。將每日站會作為一個讓他們瞭解團隊動力並提醒他們可以進行討論的機會。
你參加sprint規劃會議與否取決於你團隊的成熟度。如果團隊中有很多新面孔或者他們已經很長時間沒有用敏捷的方式工作了，那麼你的指導就非常必要。即使你有信心讓團隊在沒有你參與的情況下進行規劃，如果出現問題請務必要在規劃期間與團隊進行交流或語音聊天。
Sprint review必須始終是你的首要任務，所有人都應該參加。Sprint review是一個能讓你從所有在場的利益相關者和團隊本身獲得第一手反饋的機會。這是一個驗證假設的時間，不應該錯過。

與Scrum Master多互動

你可能會減少某些scrum儀式的參與，但應該增加與scrum master間的合作。團隊拆分後，肯定不止一個scrum master，這種情況下，你需要與他們所有人密切合作。
確保你可以信任他們，以便真實瞭解團隊的進展及sprint期間出現的任何問題。這種關係可以幫助你瞭解最新進展並且無需參加所有的scrum儀式。

scrum of scrums 介紹

時候也稱為元scrum，scrum of scrums是一個新的儀式，通常作為scrum流程規模引入。它是更高級別的站會的複製品。每個團隊都指派一名大使，所有大使每天都在S0S會議上碰面溝通進展和阻礙。這個會議還用於突出可能需要解決的任何跨團隊技術問題。

考慮擴充產品團隊

如果你的團隊設定要求產品經理積極參與到團隊中，那麼請考慮在產品方面再新增一些人員。有幾種方法可以解決這個問題：

初級產品經理。 一條途徑是讓自己承擔更具挑戰性的工作，同時增加初級產品經理來處理一些日常瑣事。他們可以承擔一些如質量保證（QA）、編寫使用者故事或為新功能建立高階模型的任務。

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

結論

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

• 站會。 如果你們的每日站會超過15分鐘的時間界限並且注意到人們開始逐漸失去興趣。
• sprint規劃 。如果你們在Sprint規劃期間越來越頻繁的陷入僵局。
• 回顧 。如果你開始注意到在回顧期間大家的意見越來越難達成一致。

所有這些跡象都表明你可能需要拆分團隊。拆分團隊看起來是一項簡單的任務但也會帶來持續的後果。如果真的要這麼做，每個產品經理都要考慮以下幾個問題：

• 團隊士氣 。理想情況下，應該讓團隊自己決定如何拆分，最大限度的減少對良好的工作關係的影響。
• 跨職能團隊 。團隊應該具備建立產品增量的所有必要技能。
• 產品backlog 。決定你的團隊是有獨立的還是一個統一的backlog。

如果需要跟蹤兩個或以上團隊則需要確定優先順序順序。高效率的產品經理應該計劃如何與新團隊保持同步：

• 優先順序會議 。思考哪些敏捷儀式是值得你花費時間參與的而哪些是可以被忽略的。
• 與scrum master互動 。讓scrum master作為你的團隊代理人，通過他們獲取團隊信
  息。
• 擴充產品團隊 。在產品團隊中新增一些成員和你一起工作，讓他們幫你完成一些日常重複性任務或進行使用者調研和市場分析。

希望通過以上幾點建議，你能有一個相對比較清晰的團隊拆分思路。

作者：VYTAS BUTKUS
翻譯/審校：吳倩倩
文章首發於Worktile官方部落格，轉載請註明出