敏捷認(rèn)為小團(tuán)隊的人數(shù)規(guī)模應(yīng)該是在魔法數(shù)字7上加減2。敏捷也推薦完整團(tuán)隊概念，就是說團(tuán)隊內(nèi)部要有足夠的技能以完成工作。因此，開發(fā)團(tuán)隊除了具備核心的開發(fā)技能，還要具有測試技能、數(shù)據(jù)庫技能、用戶界面技能。然而，很多組織仍然糾結(jié)于最佳的團(tuán)隊規(guī)模和有效的團(tuán)隊構(gòu)成。
Scott-Ambler建議：根據(jù)項目需要，可以有敏捷小團(tuán)隊和敏捷大團(tuán)隊。小團(tuán)隊有標(biāo)準(zhǔn)的Scrum角色，比如scrum-master、開發(fā)團(tuán)隊和產(chǎn)品負(fù)責(zé)人。小團(tuán)隊還可以使用支持隊伍，包括DBA、領(lǐng)域?qū)＜液蜏y試人員這樣的技術(shù)專家。大型團(tuán)隊需要“團(tuán)隊的團(tuán)隊（team of teams）”這樣的方式。Scott認(rèn)為：
典型策略是：把多個相關(guān)小團(tuán)隊組織起來，形成更大規(guī)模的團(tuán)隊，最有效的方式是圍繞著系統(tǒng)架構(gòu)的方式組織。每個子團(tuán)隊?wèi)?yīng)該負(fù)責(zé)一個或幾個子系統(tǒng)，讓他們可以像小敏捷團(tuán)隊那樣，負(fù)責(zé)按時交付可工作的軟件。這個策略常被稱為“Conway法則”，因為是Melvin Conway在二十世紀(jì)六十年代后期提出來的，也是精益開發(fā)管理策略之一。
Steve Miller認(rèn)為：除了Scrum推薦的角色之外，要想讓團(tuán)隊做好質(zhì)量保證和文檔相關(guān)工作并不現(xiàn)實。他們改進(jìn)了團(tuán)隊構(gòu)成，增加了兩個角色。軟件質(zhì)量工程師負(fù)責(zé)一個sprint的產(chǎn)出的質(zhì)量，文檔專家負(fù)責(zé)創(chuàng)建用戶指南、管理員指南和培訓(xùn)材料。
同樣地，Michael F. Dwyer在回應(yīng)Scrum Development討論組中一個有關(guān)團(tuán)隊大小的討論時指出：
趁著Ron Jeffries還沒說，我先借用他那個著名的話“2+2=5，因為這兩個粗略的‘2’要比數(shù)字2更大一點。”團(tuán)隊規(guī)?？梢允?個人這么小，也可以是500人這么大，完全基于你對團(tuán)隊的定義和成員的投入程度。
因此有一個共識：團(tuán)隊的規(guī)模和構(gòu)成要根據(jù)各個項目具體情況調(diào)整。然而，我們應(yīng)該如何評價我們的團(tuán)隊結(jié)構(gòu)是否最高效呢？
Mike Cohn建議回答下列9個問題，而且都能得到肯定回答，那就是一個結(jié)構(gòu)優(yōu)秀的團(tuán)隊。問題列表包括：
Agile talks about small team sizes with the magic numbers of 7 plus minus 2. Agile also recommends whole teams. Whole team is a concept that recommends having sufficient skills within the team itself to get the job done. This implies that the development team has the requisite testing skills, database skills, user interface skills, apart from the core development skills. However, many organizations still struggle with questions related to the optimal team size and an efficient team composition.
Scott Ambler suggested that depending on the project needs there could be small Agile teams or large Agile teams. Small teams generally have the standard roles of Scrum i.e. A scrum master, development team and a product owner. The small team could also use a supporting cast consisting of technical experts like DBAs, domain experts and testers. A large team needs a 'team of teams' approach. According to Scott,
The typical strategy is to organize your larger team into a collection of smaller teams, and the most effective way to do so is around the architecture of your system. Each subteam should be responsible for one or more subsystems, enabling them to work as a small agile team responsible for delivering working software on a timely basis. This strategy is often referred to as Conway’s Law after Melvin Conway who introduced it in the late 1960s, and is one of several lean development governance strategies.
Steve Miller suggested that along with the Scrum recommended roles, he found it unrealistic for the team to handle quality assurance and documentation well. They improved the team composition to have 2 more roles. Software quality engineer to be responsible for the quality of a sprint and a Documentation specialist for creating user guides, administrative guides and training material.
Likewise, responding to a discussion on the Scrum Development group about team sizes, Michael F. Dwyer commented that
As Ron Jeffries may be otherwise occupied I will borrow his famous tag "2 + 2 = 5 with sufficiently large enough quantities of 2". Team size can be as small a 1 and as large as 500, it all depends on your definition of team and member involvement.
Thus there is a general consensus around the need to tweak the team sizes and composition as per the project needs. However, how do you validate that you have the most efficient team structure?
Mike Cohn suggested that answering the following nine questions and getting an affirmative response to each suggests a well structured team. His list of questions include
After answering the questions do you believe that you have an efficient team structure? What tweaks did you have to make to the Agile recommendations to arrive at your efficient team structure?
ScrumCore Training. Certified ScrumMaster and Certified Product Owner public and private courses
A ScrumMaster’s Checklist: Product Owner, Team, Dev Practices, Organizational
ScrumWorks Pro is the only Scrum project management tool designed for the enterprise. Sign up for a free 35-day trial.
Back to top
Team structure
Mar 18, 2010 10:04 AM by Dave Hitchman
It is certainly complex to create a well functioning team. There are several dimensions to this:
a) Many companies view QA as separate to development, and seem to think that you can't put the two 'types of people' together. The worry is that the 'sloppy developers' will 'corrupt' the QA people and the quality will be lower. Few seem to appreciate that the QA people are just as likely to influence the developers to better standards.
b) For large products it is often tricky to create suitably 'sand boxed' parts of the product to split it between teams and still maintain a global 'look and feel'. This is actually just as true with 'prince' or similar techniques as it is for scrum, but somehow we forget to remind people of this. In many ways scrum can be an advantage here, the product owners should get together to ensure a suitable global feel to the user stories - and to include sufficient detail in the user stories to ensure the API's and GUI across the system is reasonably consistent. In fact, I have seen a failure to ensure this cause masses of problems for Symbian and its customers - there is no consistency at all between different API's. They are not the only ones with the problem.
c)Many companies have developed a 'matrix management' structure, this does actually have its uses, but what it does lead to is a tendancy to move people from project to project to make best use of their current skills and avoid developing any new ones. Thus to keep a team together for the duration of one project, let alone to develop a scrum team over a number of years, is an uphill battle. Sure 'Fred' is needed for his architectural skills today, but surely you will have designed the architecture by Friday and I can have him for Joes project? We clearly understand that the architecture may change, that those skills, along with all the experience Fred had that led to him being considered an architect, are valuable throughout the project, it is especially valuable to the team to keep Fred involved as the project progresses so he can learn how well the architecture is implemented, and what its problems are