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

Мы предпочитаем этот подход. По крайней мере, до сих пор так и было.

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

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

При планировании спринта, чтобы учесть то время, которое мы планируем потратить на устранение дефектов, мы устанавливаем уменьшенное значение фокус-фактора. Со временем команды начинают очень хорошо определять нужное значение фокус-фактора. В этом также очень помогает статистика реальной производительности (см. стр. 23 «Как команда принимает решение о том, какие истории включать в спринт?»)

Если перефразировать, то это значит: «реализовывать новые истории, вместо того, чтобы довести старые до ума». Казалось бы — да кому такое может прийти в голову? А, тем не менее, мы частенько допускали эту ошибку в начале и, я уверен, что и многие другие компании тоже. Эта неадекватность связана со стрессом. На самом деле многие менеджеры не понимают, что когда кодирование закончено, то, мы, как правило, всё ещё далеки от релиза, готового к использованию. Поэтому менеджер (или product owner) просит команду наращивать функционал продукта, в то время как груз почти-готового-к-выпуску кода становится всё тяжелее и тяжелее, замедляя весь процесс.

Допустим приемочное тестирование — это ваше самое узкое место. Например, у вас слишком мало тестировщиков или фаза приемочного тестирования забирает много времени из-за ужасного качества кода.

Допустим, команда, которая выполняет приемочное тестирование, успевает проверить 3 фичи в неделю (не подумайте, мы не используем «фичи в неделю» как метрику; я взял это для примера). Также допустим, что ваши разработчики могут сделать 6 новых фич в неделю.

Для менеджера или Product owner’а (даже для самой команды) будет искушением запланировать разработку 6-ти новых фич в неделю.

Только не это! Витать в облаках долго не получится, а когда упадёте — будет больно.

Лучше при планировании рассчитывать на 3 фичи в неделю, а оставшееся время направить на устранение узкого места. Например:

• Заставить разработчиков потестировать (приготовьтесь к «благодарности» за это…).

• Внедрить новые инструменты и скрипты, которые упростят тестирование.

• Добавить больше автоматизации.

• Сделать длиннее спринт и включить приемочное тестирование в спринт.

• Выделить несколько «тестовых спринтов», где вся команда будет работать над приемочным тестированием.

• Нанять больше тестировщиков (даже если это означает уволить некоторых разработчиков).

Мы пробовали все эти решения (кроме последнего). С точки зрения долгосрочной перспективы лучшими являются пункты 2 и 3, а именно: более эффективные инструменты, скрипты и автоматизация тестирования.

А для выявления узких мест лучше всего подходят ретроспективы.

У вас, наверное, сложилось впечатление, что у нас есть тестеры во всех Scrum-командах, и что мы обзавелись ещё одной огромной командой тестеров, которые после каждого спринта проводят приёмочное тестирование всех готовых продуктов.

Ну … это не так совсем.

У нас всего несколько раз получилось выделить время на все эти процедуры, но тогда мы на собственном опыте убедились насколько это полезно. Могу сказать, что на данный момент мы всё ещё далеки от желаемого процесса обеспечения качества, и нам по-прежнему есть чему учиться.

Когда у вас над одним продуктом работают сразу несколько Scrum-команд, всё намного сложнее. Это общая проблема и она характерна не только для Scrum'а. Чем больше разработчиков, тем больше проблем.

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

Как оказалось, ключевыми являются следующие вопросы:

• Сколько сформировать команд?

• Как распределить людей по командам?

Если настолько сложно работать по Scrum'у с несколькими командами, то зачем вообще заморачиваться? Почему просто не собрать всех в одну команду?

Самая большая Scrum-команда, которая у нас когда-либо была, состояла из 11-ти человек. И это работало, правда, не очень хорошо. Ежедневный Scrum всегда длился больше 15-ти минут. Членам команды было сложно держать в голове информацию о том, чем каждый из них занимается, из-за этого могли возникать недоразумения. ScrumMaster'у тоже было сложно направить работу в нужное русло, и было сложно найти время, чтобы разобраться со всеми возникшими трудностями.

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

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

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

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

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

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

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

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

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

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

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