Управление командой по Scrum методологии приобрело широкое использование за счет своей простоты и возможности применить «из коробки». Сложнее ситуация, когда в рамках одного проекта работает несколько команд. В этом случае применяют иерархическую модель Scrum-on-Scrum. Но вот что делать, когда есть нескольких команд разработчиков и одна команда тестеров.
Думаю любой прожект менеджер, руководивший проектом более 10 человек, встречался с такой проблемой:
• Несколько тимов работают над одним проектом. Необходимость разделить команду на несколько тимов возникает в следствии того, что проект большой, а чистый Scrum не работает для команд более 9 человек
• Группа тестировщиков меньше 9 человек и может быть сформирована в одну группу.
Самым простым решением было бы разбить тестировщиков по тимам и к каждому тиму программистов придать 1-2 тестера. Но вот что делать, если выгодно использовать тестеров, как одну группу. Это, может быть полезно если тестеры неоднородны по опыту и компетенциям. Что, как правило, присутствует всегда.
Самое простое решение, не требующее управления, это метод очереди – кто раньше таск запостил, того тестеры и начинает проверять, выгрибая сделанные таски (с учетом приоритетов) из общего пула.
Но здесь кроется проблема – тимы начинают конфликтовать под дивизом — «Почему не нас тестуют?» У самих тестеров так же возникает дискомфорт от такой ситуации и ощущение, что их «разрывают». Тестеры начинают жаловаться на нехватку ресурсов и просить увеличить количество тестеров.
Задача эта, на самом деле, имеет общий характер., Как только возникает необходимость управления командой с критическим ресурсом и множественным доступом к этому ресурсу или когда поток процесса не чисто линейный – есть блок принимающий задачи от 2х и более блоков.
Теперь я опишу решение решение, которое применил в проекте, из трех тимов девелоперов и одного тима тестеров. Тимы начинают свои спринты со сдвигом на 3 дня. Размер спринта классический – 2 недели. Тестеры берут задачи каждого отдельного тима на 4й день с начала его спринта и в 2 последних дня спринта. В результате получаем такой график.
В течении одной недели у тима тестеров есть один резервный день. Последние 2 дня тимы разработчиков планируют следующий спринт и фиксят баги из беклога, конечно не забывая и про найденные баги текущего спринта. Такая организация помогла снять напряжение с тестеров и повысить ответственность разработчиков. Сложные таски делаются сначала спринта, для проверки на 4-й день спринта. Разработчики так же понимают, что сдавать желательно проверенные решения в конце спринта, иначе баг найденный в последний день придется переносить в следующий спринт не закрывая таск.
Комментарии (18)
bniwredyc
22.12.2015 20:49Решали такую задачу в Kaiten.io
Есть клиент, у которого одна команда разработчиков, получает задачи от нескольких департаментов.
Если взять кейс из статьи, то выглядеть у нас это будет так:
Разработчики могут самостоятельно отправлять задачи в очередь на тестирование, но при этом должны соблюдать установленный лимит (на картинке разработчики из первой команды не могут отправить задачу в тестирование, а разработчики второй могут).
Тестировщики берут задачи из очереди в соответствии с FIFO-маркерами (цифры в квадратике в заголовке карты), которые проставляются в момент попадания задачи в очередь.
dovnmr
22.12.2015 22:46В принципе идея та же — дискритизировать задачи и ограничить их поступление к тестировщикам. Предложенное мною решение имеет, как мне кажется, преимущество — девелоперы делают таски, как обычно и заэмаиневают их на тим QA. Для них картина процесса не меняется. Используется обычная система TFS (например Jira или Microsoft). Тим QA выбирает каждый день таски с разными метками тимов.
Мне кажется технологически это проще. Хотя up to youIvan22
23.12.2015 10:24разница в том, что не нужны выделенные дни — в тест можно брать когда удобно. Ну и разработка не прерывается, но это уже фишка канбана.
bniwredyc
23.12.2015 13:16Ну да. Вот ещё хотел спросить:
1. Как решаются ситуации когда тестеры не успевают даже с учётом резервного дня?
2. Если тестеры всё успели, что они делают в резервный день?dovnmr
23.12.2015 13:42Вопросы не простые.
У нас резервный день идет на:
— тесты для продакшен (но когда он наступает. то вообще все может рушиться и тимы берут Creative week, что бы не грузить тестеров)
— самообразование, например разделы автоматического тестирования
— документация, в часности создание новых тест кейсов
Если тестеры не успевают, тут та же проблема, что и не успевает тим в спринте. Во время планирования спринта задачи берутся с учетом времени на тестирование, так что это симтом плохого планирования спринтаbniwredyc
23.12.2015 13:58Спасибо за ответы, интересно.
Имхо вы бы могли тестеров пересадить на канбан с хитрой очередью, а разработчики продолжили бы по скраму работать.dovnmr
23.12.2015 14:11Выделение тестеров в отдельную модель по скраму или кабану мне не кажется перспективной. Дело в том, что главная задача закрыть спринты команд и сделанная девелоперами разработка не может просто повиснуть — ее надо закрыть тестами. Поэтому они не отьемлемая часть спринтов девелоперов.
Но честно методика еще в разработке — я не нашел оптимального решения и главная моя проблема — разный велосити на разработку и тестинг тасковnittis
24.12.2015 12:35А подходит ли скрам при такой организации производства?
Скрам предполагает работу кросс-функциональных команд, которые полностью отвечают за выполнения задачи, от её оценки и технической постановки до выпуска (подготовки) релиза. Здесь же получается, что команда зависит от отдела тестирования.
Тестировщики присутствуют на планировании и принимают участие в оценке задач?
Как команда разработчиков может взять обязательства на спринт, если она не управляет частью процесса? не знает сколько времени потребуется на тестирование и какова будет загрузка у тестировщиков?
dovnmr
24.12.2015 12:38Тестировщики присутствуют на спринтах и дают свою оценку, но это не меняет проблематику — приходиться уменьшать велосити.
nittis
24.12.2015 12:48Кажется, что у приведенной схемы есть немало других недостатков.
Например, необходимость синхронизации спринтов.
Неясно чем занимаются разработчики последние 2 дня спринта, когда основная активность — это тестирование
Добавление четвертой команды разработчиков разрушит всю стройность системы.
Команда не может управлять длительностью спринта. Что если кто-то захочет сократить её до недели, например при старте нового проекта когда важно получать быструю обратную связь.
Как вносить коррективы в случае праздников, больничных и отпусков
dovnmr
24.12.2015 12:53Простите, но вы не внимательно читали :(
Я писал, чем занимаются тимы последние 2 дня — баги из беклога
Что касается 4го, тима, то действительно придется увеличивать размер спринта. Это решение имеет ограничения. Работает в размере общей команды 20-30 человек
Изменения размеров спринта, действительно не предусмотрены, но это не является минусом, на мой взгляд.
Коррективы по праздникам вносятся просто — сдвиг. Остальные изменения моделью скрама не предусмотрены и на мой взгляд ведут к анархииIvan22
24.12.2015 17:10А почему действительно не принять канбан? Неприрывная интеграция и непрерывный канбан.
Ivan22
Странно, если есть приоритеты и очередь, совершенно прозрачно же видно, кого и когда будут тестировать!
dovnmr
Как правило приоритеты тасков не более трех. 80% попадают в одну категорию. Таски стараются быть предельно мелкими — принцип Agile. В этом случае за 1 день каждая команда может сделать несколько тасков. В итоге тим тестеров получает десяток тасков за 1 день. Функциональное тестирование даже в «сером» варианте занимает не менее часа (подготовка среды и пр.)
И все становиться совсем не очевидным
Ivan22
ну приоритизацию надо сделать в виде очереди fifo с номерами (внутри каждой категории)… 1 -2 -3 -4- 5. Думаю понятно как это выглядит.