Стоит ли изменять состав команды между спринтами?
Обычно каждый спринт обладает своими собственными особенностями в зависимости от того, какого рода задачи мы пытаемся решить. Как следствие, оптимальный состав команды для каждого спринта может отличаться.
Фактически, почти каждый спринт нам приходилось говорить себе что-то вроде: «этот спринт не совсем обычный спринт, потому что (ля-ля-ля)…». Через некоторое время мы прекратили использовать понятие «обычный» спринт. Обычных спринтов просто нет. Так же как нет «обычных» семей или «обычных» людей.
Для одного спринта может показаться хорошей идеей, создать команду, которая занимается клиентской частью приложения и включает в себя всех, кто хорошо знает код клиента. Для другого спринта хорошей идеей может быть создание двух универсальных команд и разделение специалистов по клиентской части между ними.
Одним из ключевых аспектов Scrum'а является «сработанность команды», т. е. если члены команды работают вместе в течение многих спринтов, они обычно становятся очень сплоченными. Они научатся входить в групповой поток, и достигнут невероятного уровня продуктивности. Но чтобы достичь этого требуется несколько спринтов. Если вы будете часто изменять состав команды, то вы никогда не достигнете настоящей командной сработанности.
Поэтому, если вы решили изменить состав команды, учитывайте все последствия. Будут ли это долговременные или кратковременные изменения? Если кратковременные, стоит их пропустить. На долговременные изменения можно пойти.
Есть одно исключение: большая команда, которая только-только начала работать по Scrum’у В этом случае возможны некоторые эксперименты с разделением команды на подкоманды, пока не будет найден вариант, который полностью устраивал бы всех. Удостоверьтесь, что все понимают, что отрицательный результат — тоже результат, что первые несколько итераций могут быть комом — и это нормально, при условии, что вы работаете над улучшениями.
Участники команды с частичной занятостью
Могу только подтвердить то, что говорят книги, посвящённые Scrum’у наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.