Я, возможно, опять покажусь занудой, но у меня magic numbers всегда вызывают подозрения.Тут вот какая ситуация. Размер эффективно работающей команды для сложных задач - 5-7 человек. Это выявлено на опыте и проверено экспериментально, например, Белбиным. При большем количестве человек - возрастают накладные расходы на коммуникации, при меньшем - не хватает разнообразия личностей. Потому что команда действительно должна работать автономно, не нуждаясь во внешнем вмешательстве, что, в том числе, означает дублирование, достаточное чтобы болезнь или отпуск одного человека не сказались на автономности команды (а в идеале - если при двух отсутствующих она все равно работала). При таком ограничении сверху внутри команды не может быть слишком много специализаций, и они должны касаться тех активностей, которых много. Собственно, поэтому мы пришли к тому, что роли аналитика и тестировщика совмещаются - тогда в команде есть разработчики, аналитики-тестировщики и еще руководитель, для которого тоже обычно есть дублер.
"Для решения сложных задач" звучит как "среднее по больнице". Я видел команды меньше (больше, кстати, редко видел) и им всего хватало. Не назвал бы их задачи простыми. Для разных задач нужны разные наборы специализаций.
Мне в свое время довелось работать в команде, размер которой менялся от 2 до 8 человек на разных стадиях проекта. Это работало. Более того - ничего страшного в этом небыло, т.к. объемы работ менялись время от времени, а в компании производили продукты такие, что переключение с одного на другой много времени не занимало.
В достаточно больших проектах опять же приходится разбивать работы по проекту на несколько комнд.
Кстати, в командах с руководителями я не работал уже года четыре как.
Это для вас тестирование производительности это временная активность. Для ряда продуктов она практически непрерывная. В ряде случае оно решается проще - выделенные команды дизайнеров/администраторов/нагрузки/прочих специалистов. Часто, кстати, команда консультирует профессионала, а не наоборот.Если брать специфические активности, например, тестирование производительности или тестирование юзабилити интерфейса, то это - временная активность в ходе проекта. Соответственно, вариантами является аутсорсинг профессионалу (наружу команды), или временное введение профессионала в команду, или привлечение профессионала как консультанта. С моей точки зрения, нынешний тренд - возлагать на команду с консультациями профессионала, в отличие от предыдущего тренда - передачи профессионалам. Все это не исключает проектов, где соответствующие требования - критичны, и потому в команде должны быть профессионалы с опытом по ним.
Я не люблю тренды, потому, что они бессмысленны сами по себе. Это просто шаблоны, которые ни к чему не обязывают и ничего не гарантируют. У всех свой контекст. У всех своя специфика проектов/задач/людей/законодательства/прочаяпрочая. Перекладывать на них тренды в слепую глупо, так что в итоге все равно нужно делать свое.
ЗЫ: Кстати, в фазу тестирования я уже давно не верю. Но это отдельный разговор.