Управление командой по Scrum методологии приобрело широкое использование за счет своей простоты и возможности применить «из коробки». Сложнее ситуация, когда в рамках одного проекта работает несколько команд. В этом случае применяют иерархическую модель Scrum-on-Scrum. Но вот что делать, когда есть нескольких команд разработчиков и одна команда тестеров.
Думаю любой прожект менеджер, руководивший проектом более 10 человек, встречался с такой проблемой:
• Несколько тимов работают над одним проектом. Необходимость разделить команду на несколько тимов возникает в следствии того, что проект большой, а чистый Scrum не работает для команд более 9 человек
• Группа тестировщиков меньше 9 человек и может быть сформирована в одну группу.
Самым простым решением было бы разбить тестировщиков по тимам и к каждому тиму программистов придать 1-2 тестера. Но вот что делать, если выгодно использовать тестеров, как одну группу. Это, может быть полезно если тестеры неоднородны по опыту и компетенциям. Что, как правило, присутствует всегда.
Самое простое решение, не требующее управления, это метод очереди – кто раньше таск запостил, того тестеры и начинает проверять, выгрибая сделанные таски (с учетом приоритетов) из общего пула.
Но здесь кроется проблема – тимы начинают конфликтовать под дивизом — «Почему не нас тестуют?» У самих тестеров так же возникает дискомфорт от такой ситуации и ощущение, что их «разрывают». Тестеры начинают жаловаться на нехватку ресурсов и просить увеличить количество тестеров.
Задача эта, на самом деле, имеет общий характер., Как только возникает необходимость управления командой с критическим ресурсом и множественным доступом к этому ресурсу или когда поток процесса не чисто линейный – есть блок принимающий задачи от 2х и более блоков.
Теперь я опишу решение решение, которое применил в проекте, из трех тимов девелоперов и одного тима тестеров. Тимы начинают свои спринты со сдвигом на 3 дня. Размер спринта классический – 2 недели. Тестеры берут задачи каждого отдельного тима на 4й день с начала его спринта и в 2 последних дня спринта. В результате получаем такой график.
В течении одной недели у тима тестеров есть один резервный день. Последние 2 дня тимы разработчиков планируют следующий спринт и фиксят баги из беклога, конечно не забывая и про найденные баги текущего спринта. Такая организация помогла снять напряжение с тестеров и повысить ответственность разработчиков. Сложные таски делаются сначала спринта, для проверки на 4-й день спринта. Разработчики так же понимают, что сдавать желательно проверенные решения в конце спринта, иначе баг найденный в последний день придется переносить в следующий спринт не закрывая таск.
