敏捷項目源于消除廣泛、低效率瀑布式方法：軟件通常會延遲交付，而且并沒有按照設(shè)計的那樣滿足用戶的需求。與瀑布式方法不同，敏捷項目只有代碼編譯完成后才能進行測試，敏捷項目能夠很好地保持軟件開發(fā)流程的運行。例如對軟件各部分迭代進行測試這樣的實踐能有助于項目取得穩(wěn)定的發(fā)展，并且顯示出只涉及該團隊的項目。
隨著開發(fā)周期的縮短，團隊成員間持續(xù)的軟件交付、共同承擔的角色和職責，使得敏捷軟件開發(fā)的效率有所提高。但是當敏捷開發(fā)項目發(fā)展到包含多個團隊的時候，團隊成員工作地點不同，經(jīng)常會相隔很遠，此時又會發(fā)生什么樣的變化呢?當團隊成員無法在同一間屋子內(nèi)工作時，他們該如何一如既往的堅持遵守工作原則呢?
多倫多敏捷咨詢公司Scott Ambler及其附屬公司的創(chuàng)始人Scott Ambler說：“如果敏捷項目范圍超過一個團隊時，項目運行就會出現(xiàn)問題?！泵艚蓓椖恳?guī)模擴大，就會增大了敏捷項目起初打算縮減的管理負載。面臨的挑戰(zhàn)是：軟件公司要如何管理多團隊的敏捷項目，并且不失其敏捷特性。
根據(jù)敏捷項目專家所說，完全消除這些風險是不可能的。畢竟，與獨立團隊的敏捷項目相比，多團隊敏捷項目需要投入更多管理。重復工作是不可避免的，一些技術(shù)有助于多團隊在一個項目中協(xié)同工作，并保證敏捷軟件開發(fā)的高效性。
阿林頓Rothman咨詢有限公司的創(chuàng)始人Johanna Rothman認為，如何設(shè)置這些團隊的組織架構(gòu)，如何分配工作任務(wù)以及如何管理這些組織之間的依賴關(guān)系是判斷成功還是失敗的標志。Rothman的解釋是：“于細微處見真章”。
1、所需的適當技能
Rothman認為，當多團隊項目組開始工作時，保持小型團隊是保證項目敏捷性的關(guān)鍵。她建議團隊成員數(shù)量以5-7人為最佳。Rothman并不建議擴大團隊成員數(shù)量，而是建議團隊決定如何增加團隊成員在敏捷項目中所缺乏的技能。她接觸的一些顧客認為，沒有足夠的人能完全掌握敏捷開發(fā)項目所需技能?！八麄冋f：‘我們沒有足夠多的測試人員、DBA和用戶體驗專家?！?/span>
Ambler同意以上觀點。他說，企業(yè)希望團隊自身具備完成工作所需的技能?！暗沁@樣做有風險。團隊需要利用企業(yè)資源，與企業(yè)架構(gòu)師合作，重復使用工作人員以及數(shù)據(jù)庫人員?！?/span>
2、適宜的團隊成員數(shù)量
轉(zhuǎn)向多團隊敏捷項目是個不小的壯舉。敏捷項目咨詢師James Shore說，在沒有完全掌握獨立團隊敏捷項目開發(fā)過程之前，不要采用多團隊敏捷項目，這一點非常重要。這聽上去是很明顯的，但是Shore曾經(jīng)見過許多公司在沒有獨立團隊開發(fā)敏捷項目經(jīng)驗的情況下就引入多團隊敏捷項目模式。他認為，這必然會失敗?！斑@是在做跳躍式改變。如果企業(yè)沒有按照漸進式的方式來開發(fā)敏捷項目，那么很快就會出現(xiàn)溝通和編碼質(zhì)量問題?！?/span>
敏捷項目的獨立團隊一般以少于10人為宜。Shore認為，一旦團隊成員數(shù)量達到10或者12人，那么最好成立兩個團隊。他提到，他的合作伙伴Diana Larsen(俄勒岡州波特蘭市的Future Works敏捷項目咨詢公司的合作伙伴)認為一個團隊最佳的成員數(shù)為“五到九人。” Shore說，一旦團隊成員數(shù)目過多，就要考慮將一個團隊分為兩個團隊。“即使名義上團隊成員還是屬于同一個團隊，但是他們已經(jīng)形成兩個小團體，不同時在一個團隊工作了。無論你是否承認，一個團隊都被分成兩個相互依賴的團隊?！?/span>