Кто и чем занимается на протяжении спринта?
Agile. Scrum. Sprint.
Разработчики, Тестировщики.
День первый.
Берем таски из беклога.
Беклог периодически нужно просматривать, сортировать по приоритету(нужные таски выше, бесполезные ниже) и чистить. Кто должен это делать? Продукт овнер - представитель бизнеса, тимлиды, старшие разработчики - представители разработки. Представитель бизнеса не даст откладывать важные для бизнеса задачи, представители разработки не дадут понижать важность технических задач.
Оцениваем задачи по сложности. Распределяем нагрузку между разработчиками.
Начинается разработка. Что делают тестировщики пока нет результата разработки?
Разработка закончилась. Тестировщики начали тестировать. Что делают разработчики?
При тестировании найден баг. Разработчик делает фикс. Тестировщик проверяет фикс. Нужно ли еще раз проходить предыдущие тест кейсы? Теоретически после фикса, ранее проверенный функционал мог сломаться.
День последний.
Вариант оторванный от реальности.
На первый день спринта и тестировщики и разработчики свободны - не заняты работой. Пока идет разработка, тестировщики ни чего не делают. Как только основная разработка завершена, тестировщики начинают тестирование. Разработчики ни чего не делают. Найден баг. Разработчики свободны и правят баг. Тестировщики проверяют баг и начинают тестирование заново. Если взять спринт длиной в неделю(5 рабочих дней). Три дня разработки, два дня тестирования. Откуда эти цифры? Релиз на 6 день - начало следующего спринта.
Проблемы:
- тестировщики и разработчики попеременно не заняты
Вариант ближе к реальности
Как только основная разработка завершена, разработчик переключается на следующую задачу(вторичную). При выявлении бага в основной задаче, переключается и фиксит. Возвращается к следующей задаче.
Проблемы:
- разработчик теряет фокус при переключении между задачами
- готовятся задачи к релизу, которые требуют тестирования
- тестировщики все еще не заняты пока ведется разработка по основной задаче
Как исключить потерю фокуса разработчика? Разработчик сдает задачу в тест. Начинается тестирование. Переключается на следующую задачу и не переключается на фикс потенциальных багов, пока не достигнет контрольной точки. Это либо завершение задачи, либо конец рабочего дня. Во втором случае фикс будет сделан в начале след.рабочего дня. В таком случае будет меньше переключений контекста для разработчика и тестировщики возможно найдут еще несколько багов, тогда разработчику будет проще их пофиксить пачкой.
Когда тестировать вторичные задачи? Возможно это решит третью проблему, пока разработчики заняты основной задачей, тестировщики тестируют вторичные задачи прошлого спринта. Перед началом тестирования основной задачи будет релиз вторичных задач прошлого спринта.
Возможное решение третьей проблемы. После релиза основной задачи, тестировщики могут переключиться на написание автотестов выпущенной задачи.
Вывод
Кажется, спринта длиной в 1 неделю недостаточно. Не будет хватать времени для вторичных задач, переключение на фикс багов по достижению контрольной точки будет выглядеть неоптимальным расточительством времени. Спринт длиной в две недели будет лучше. Но нужно ограничить длину основной разработки - не более одной недели. На этой же неделе(первой неделе спринта) - тестирование вторичных задач предыдущего спринта. Вторая неделя - тестирование основной задачи, фиксы багов основной задачи, разработка вторичных задач.
Время на разработку основной задачи стоит вписывать в одну неделю. Подготовительную работу к основной задаче нужно добавлять как вторичные задачи в спринт перед началом основной разработки.