Home

Автор: Султанов Илья, тимлид разработки, @sultanovis

В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.

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

Итак, к делу.

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

Но подожди, отвечаю я руководителю, ведь пока идет тестирование, разработчик либо будет простаивать, либо возьмется за другую задачу, и ему придется прерываться, ну или третий вариант - будет делать задачу до конца спринта, и исправление багов уйдет на следующий спринт, и всё будет не слишком здорово?

"У меня 15 лет опыта в разработке, и всегда так работали, и ты сможешь!" - подбодрил руководитель и отключился. А я призадумался.

По сути, руководитель поставил мне 3 условия:

1. Все задачи спринта должны быть завершены в спринт;

2. Разработка и тестирование должны быть в одном спринте;

3. Все баги должны быть исправлены в этом же спринте;

Поставленные условия сразу и жестко привязывают процессы разработки, тестирования и исправления багов друг к другу. При таком подходе, когда есть прямая зависимость между звеньями, рабочий процесс будет постоянно лихорадить. Обычно это пытаются уладить волевыми решениями и жесткими требованиями руководства «лучше декомпозировать задачи», и это никогда не работает. А работать будет только при обеспечении слабой связности процессов разработки, тестирования и исправления багов.

Приведу пример из другой сферы.

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

Перейдем обратно к нашим баранам фичам, и попробуем запланировать спринт по тем условиям, которые поставлены руководителем.

Обычно при планировании спринта тимлид (и его команда, конечно же) сталкиваются с одним фактором неопределенности - временем выполнения задач. За счет компетенций команды, обсуждения и декомпозиции, ну и некоторого запаса по времени в спринте (оставляем разработчику пару дней свободными) этот фактор неопределенности преодолевается, и процесс разработки становится предсказуемым. Более или менее.

В случае же представленных граничных условий число факторов неопределенности возрастает до трех - это время выполнения спринтовых задач, момент передачи багов разработчику (это конечно очень неожиданно, но у тестировщиков тоже случаются завалы и они тоже болеют), и время отработки самих багов. При этом предварительно рассмотреть и оценить мы можем только спринтовые задачи. Спринт у нас стандартный – две недели, то есть 10 рабочих дней, из них примерно день (8 часов) уходит на обязательные встречи, митинги и ритуалы аджайл. То есть из 9 оставшихся дней я могу планировать работы только дня на 4, а остальное оставлять на запас и баги, при этом я даже не знаю, придут ли эти самые баги в спринт. Ну или говорить разработчику "твои косяки - ты и исправляй в свободной от работы время".

Но, как говорили наши мудрые предки, "критикуешь - предлагай". Да и решение вобщем-то на поверхности. Нужно не пытаться впихнуть невпихуемое объять необъятное, а использовать бэклог спринта для отвязки процессов друг от друга.

Иными словами, необходимо организовать процесс так:

1. Разработчик берет задачи в спринт и разрабатывает, складывая в бэклог следующего спринта тестировщиков;

2. Тестировщики в плановом порядке берут задачи в свой спринт, складывают баги в бэклог разработчиков;

3. Разработчики в плановом порядке берут в спринт баги с высшим приоритетом, и потом уже спринтовые задачи, исправленные баги складывают в бэклог тестировщикам на проверку;

4. Тестировщики проверяют исправление багов и ставят свой одобрямс. Фича готова.

Мы видим, что процесс полного тестирования занимает 4 спринта, зато всё предсказуемо, планово, оцениваемо и без кризисов, которые мы создаем себе сами.