Спринт с багами, или как (не) создать себе проблем
В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.
Они чувствительны и сентиментальны. Даже исправлять жалко.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь делать разработку предсказуемой. Иногда даже получается.
Итак, к делу.
В один прекрасный день работаю я, никого не трогаю, и тут приходит ко мне руководитель и говорит: «Неправильно ты, дядя Федор, бутерброд ешь!» «У тебя неправильно распланированы спринты. Необходимо, чтобы задачи выходили из спринта уже протестированные и с исправленными багами, иначе мы не сможем их закрывать!». И тут же обрисовал всё схематично, примерно вот так:
Вроде все хорошо. Теоретически
Но подожди, отвечаю я руководителю, ведь пока идет тестирование, разработчик либо будет простаивать, либо возьмется за другую задачу, и ему придется прерываться, ну или третий вариант — будет делать задачу до конца спринта, и исправление багов уйдет на следующий спринт, и всё будет не слишком здорово?
На практике уже не очень хорошо
Ну или очень нехорошо. Как повезет
«У меня 15 лет опыта в разработке, и всегда так работали, и ты сможешь!» — подбодрил руководитель и отключился. А я призадумался.
По сути, руководитель поставил мне 3 условия:
Все задачи спринта должны быть завершены в спринт;
Разработка и тестирование должны быть в одном спринте;
Все баги должны быть исправлены в этом же спринте;
Поставленные условия сразу и жестко привязывают процессы разработки, тестирования и исправления багов друг к другу. При таком подходе, когда есть прямая зависимость между звеньями, рабочий процесс будет постоянно лихорадить. Обычно это пытаются уладить волевыми решениями и жесткими требованиями руководства «лучше декомпозировать задачи», и это никогда не работает. А работать будет только при обеспечении слабой связности процессов разработки, тестирования и исправления багов.
Приведу пример из другой сферы.
Абсолютно во всех более-менее массовых промышленных процессах есть некие склады, запасы, фонды. В каждом магазине, на каждом производстве есть склад, чтобы обеспечивать стабильность работы и отвязать подвоз запасов от производства и продаж. Если попытаться работать без склада, то товар на полках магазинов, сырье на производстве будет периодически (и совершенно внезапно) заканчиваться, а запас не создать — склада-то нет. В таких случаях любое планирование будущих периодов практически перестает иметь смысл, и работа средних менеджеров превращается в постоянное преодоление кризисов.
Перейдем обратно к нашим баранам фичам, и попробуем запланировать спринт по тем условиям, которые поставлены руководителем.
Обычно при планировании спринта тимлид (и его команда, конечно же) сталкиваются с одним фактором неопределенности — временем выполнения задач. За счет компетенций команды, обсуждения и декомпозиции, ну и некоторого запаса по времени в спринте (оставляем разработчику пару дней свободными) этот фактор неопределенности преодолевается, и процесс разработки становится предсказуемым. Более или менее.
В случае же представленных граничных условий число факторов неопределенности возрастает до трех — это время выполнения спринтовых задач, момент передачи багов разработчику (это конечно очень неожиданно, но у тестировщиков тоже случаются завалы и они тоже болеют), и время отработки самих багов. При этом предварительно рассмотреть и оценить мы можем только спринтовые задачи. Спринт у нас стандартный — две недели, то есть 10 рабочих дней, из них примерно день (8 часов) уходит на обязательные встречи, митинги и ритуалы аджайл. То есть из 9 оставшихся дней я могу планировать работы только дня на 4, а остальное оставлять на запас и баги, при этом я даже не знаю, придут ли эти самые баги в спринт. Ну или говорить разработчику «твои косяки — ты и исправляй в свободной от работы время».
Но, как говорили наши мудрые предки, «критикуешь — предлагай». Да и решение вобщем-то на поверхности. Нужно не пытаться впихнуть невпихуемое объять необъятное, а использовать бэклог спринта для отвязки процессов друг от друга.
Всё спокойно, без рывков и героизма
Иными словами, необходимо организовать процесс так:
Разработчик берет задачи в спринт и разрабатывает, складывая в бэклог следующего спринта тестировщиков;
Тестировщики в плановом порядке берут задачи в свой спринт, складывают баги в бэклог разработчиков;
Разработчики в плановом порядке берут в спринт баги с высшим приоритетом, и потом уже спринтовые задачи, исправленные баги складывают в бэклог тестировщикам на проверку;
Тестировщики проверяют исправление багов и ставят свой одобрямс. Фича готова.
Мы видим, что процесс полного тестирования занимает 4 спринта, зато всё предсказуемо, планово, оцениваемо и без кризисов, которые мы создаем себе сами.
Да-да, именно ты!
