Хенрик Книберг - Scrum и XP - заметки с передовой

Как вариант, можно выделить две команды. Но будет ли это лучше? Не факт.

Если команда опытная, ей комфортно работать по Scrum'у, и вы знаете, как правильно разделить работу на два отдельных направления, что позволит избежать одновременной работы над одними и теми же исходниками, тогда я скажу, что это хорошая идея: разделить на отдельные команды. В противном же случае, не смотря на все минусы работы в большой команде, я бы подумал о том, как оставить одну большую команду.

Мой опыт показывает, что намного лучше иметь несколько больших команд, чем много маленьких, которые постоянно будут мешать друг другу. Создавайте маленькие команды только тогда, когда они не нуждаются во взаимодействии друг с другом.

Как же понять, насколько правильно были оценены преимущества и недостатки при выборе между «большой командой» или «несколькими командами»?

Будьте предельно внимательны, и вы заметите формирование «виртуальных команд».

Пример 1:Вы остановились на одной большой команде. Но как только начнёте наблюдать за тем, кто с кем общается на протяжении спринта, то заметите, что команда фактически разбивается на две подкоманды.

Пример 2:Вы решили сделать три небольшие команды. Но как только начнёте прислушиваться, кто и с кем говорит в ходе спринта, то заметите, что первая и вторая команды общаются между собой, тогда как третья работает сама по себе.

Что бы это значило? Что ваша стратегия разделения была неправильной? И да (если виртуальные команды постоянные) и нет, (если виртуальные команды временные).

Взгляните ещё раз на первый пример. Если состав обеих виртуальных подкоманд меняется (т. е. люди переходят из одной виртуальной подкоманды в другую), тогда возможно вы приняли правильное решение, создав одну большую Scrum-команду. Если же две виртуальные подкоманды в ходе спринта остаются неизменными, то, возможно, для следующего спринта их следует разбить на две настоящие независимые Scrum-команды.

Теперь вернёмся ко второму примеру. Если первая и вторая команды общаются друг с другом (но не с третьей) на протяжении всего спринта, тогда возможно для следующего спринта следует объединить первую и вторую команду в одну Scrum-команду. Если первая и вторая команда очень плотно общаются в первой половине спринта, а во второй половине спринта уже первая и третья команды ведут оживлённые беседы друг с другом, тогда думаю, вам стоило бы рассмотреть возможность объединения всех трёх команд в одну, или всё-таки оставить эти команды как есть. Поднимите этот вопрос на ретроспективе и дайте возможность командам самим решить его.

Разбиение на команды — это действительно одна из самых сложных задач в Scrum'е. Не пытайтесь копать очень глубоко или заниматься очень сложной оптимизацией. Экспериментируйте, наблюдайте за виртуальными командами, и не забывайте уделять обсуждению этого вопроса достаточно времени на ретроспективах. Рано или поздно вы найдёте для себя правильное решение. Однако запомните, что вам следует сделать всё, чтобы команды чувствовали себя комфортно и не мешали друг другу слишком часто.

Практически во всех книгах, которые я читал, утверждается, что «оптимальный размер» команды составляет примерно 5–9 человек.

Исходя из того, что я видел, остаётся только согласиться с этим мнением. Хотя, как по мне, всё-таки лучше иметь команду от 3-ёх до 8-ми человек. Поднапрягитесь, но создайте команды такого размера.

Допустим, у вас есть одна Scrum-команда из 10-ти человек. Подумайте, может быть стоить выкинуть двух наиболее слабых участников команды. Ой-йо-йой, я что — правда, сказал это?

Предположим, вы разрабатываете два разных продукта, у вас по три человека в каждой команде, однако обе команды работают очень медленно. Может быть , их следует объединить в одну команду из 6-ти человек. И пусть эта команда одновременно создаёт оба продукта. В этом случае одному из двух product owner'ов придётся уйти (или начать играть роль консультанта, ну или ещё что-то наподобие этого).

Допустим, у вас одна Scrum-команда из 12 человек, которую нереально разбить на две независимые команды только потому, что исходный код страшно запущен. Вам придётся приложить максимум усилий, чтобы отрефакторить (вместо того чтобы клепать новый функционал) исходный код до такой степени, чтобы над ним могли работать независимые команды. Поверьте мне, что, скорее всего, ваши «инвестиции» окупятся с лихвой.