敏捷認為小團隊的人數(shù)規(guī)模應該是在魔法數(shù)字7上加減2。敏捷也推薦完整團隊概念，就是說團隊內(nèi)部要有足夠的技能以完成工作。因此，開發(fā)團隊除了具備核心的開發(fā)技能，還要具有測試技能、數(shù)據(jù)庫技能、用戶界面技能。然而，很多組織仍然糾結于最佳的團隊規(guī)模和有效的團隊構成。
Scott Ambler建議：根據(jù)項目需要，可以有敏捷小團隊和敏捷大團隊。小團隊有標準的Scrum角色，比如scrum master、開發(fā)團隊和產(chǎn)品負責人。小團隊還可以使用支持隊伍，包括DBA、領域?qū)＜液蜏y試人員這樣的技術專家。大型團隊需要“團隊的團隊（team of teams）”這樣的方式。Scott認為：
典型策略是：把多個相關小團隊組織起來，形成更大規(guī)模的團隊，最有效的方式是圍繞著系統(tǒng)架構的方式組織。每個子團隊應該負責一個或幾個子系統(tǒng)，讓他們可以像小敏捷團隊那樣，負責按時交付可工作的軟件。這個策略常被稱為“Conway法則”，因為是Melvin Conway在二十世紀六十年代后期提出來的，也是精益開發(fā)管理策略之一。
Steve Miller認為：除了Scrum推薦的角色之外，要想讓團隊做好質(zhì)量保證和文檔相關工作并不現(xiàn)實。他們改進了團隊構成，增加了兩個角色。軟件質(zhì)量工程師負責一個sprint的產(chǎn)出的質(zhì)量，文檔專家負責創(chuàng)建用戶指南、管理員指南和培訓材料。
同樣地，Michael F. Dwyer在回應Scrum Development討論組中一個有關團隊大小的討論時指出：
趁著Ron Jeffries還沒說，我先借用他那個著名的話“2+2=5，因為這兩個粗略的‘2’要比數(shù)字2更大一點?！眻F隊規(guī)模可以是1個人這么小，也可以是500人這么大，完全基于你對團隊的定義和成員的投入程度。
因此有一個共識：團隊的規(guī)模和構成要根據(jù)各個項目具體情況調(diào)整。然而，我們應該如何評價我們的團隊結構是否最高效呢？
Mike Cohn建議回答下列9個問題，而且都能得到肯定回答，那就是一個結構優(yōu)秀的團隊。問題列表包括：
團隊的結構是否強調(diào)自身的長處，支撐短處，而且支持、激勵團隊成員？團隊某個成員的弱點應該可以被其他成員的優(yōu)勢所補足。
團隊結構是否將必須同時屬于兩個團隊的人員數(shù)目降到最低（而且避免有人同時屬于三個團隊）？試圖同時著手多個并行項目、或是多個任務，都會損害進度。
團隊結構是否能將團隊保持在一起的時間延至最長？應該更傾向于讓成員能夠在長期內(nèi)保持在一起的團隊設計，這能讓團隊的感覺和聯(lián)系保持長久。
組件團隊的結構是不是只在有限而且易于處理的情況下使用？團隊應該是功能團隊，圍繞著端到端交付可工作功能的方式構建。
是不是兩個pizza這樣的食物數(shù)量足夠多數(shù)團隊食用？大多數(shù)設計良好的團隊應該有7±2個人。
團隊結構能夠?qū)F隊之間的溝通路徑數(shù)目最小化？如果在待開發(fā)應用中做一個小更改，就會帶來大量團隊之間的溝通，那么就得好好看看團隊結構了。
現(xiàn)有結構是否鼓勵團隊溝通？如果換個結構，團隊就不愿意這么做？高效的團隊設計鼓勵團隊或個人之間的溝通，可能他們本來不想這么做。
團隊設計是否支持對于責任的明確理解？結構應該推進共享所有權和共同成功的理念。
團隊成員是否可以對團隊設計提出建議？他們應該感到這是他們構建起來的團隊。
在回答完上述問題后，您是否相信您有高效的團隊架構？為了讓敏捷的做法幫您實現(xiàn)高效團隊架構，您過去采取了哪些必要措施？