Как уложить тестирование фичи внутрь спринта?
Когда команда с горем пополам научилась попадать с разработкой запланированного внутрь спринта, то встает следующий вопрос - а почему мы все равно не успеваем впихнуть то, что уже было разработано в релиз после спринта?
У нас именно так и получилось. Вначале разработчики не использовали никакой системы при планировании спринта - это было больше похоже на индивидуальное планирование, каждый брал себе столько сколько сможет унести, и конечно результат спринта был достаточно рандомным. Что конечно расстраивало заказчиков, никто не понимал - когда же будет доставка конкретной фичи?
После внедрения poker planning и story points, ситуация с прогнозированием разработки улучшилась значительно. Но заказчики (Product Managers в нашем случае) инстинктивно воспринимали завершение разработки как готовность фичи. Это конечно было ошибочное ожидание, более того, когда PM смотрели на каждую фичу и видели:
Фича A -> 3 Story Points
Фича B -> 8 Story points
То ошибочно думали, что тестирование будет занимать пропорциональное количество времени, то есть например:
Фича A -> 1 день?
Фича B -> 2 дня?
Но в реальности объем тестирования никак не был связан с Dev Effort по разработке конкретной фичи. Все могло быть с точностью до наоборот:
Фича A -> 3 дня
Фича B -> 1 день
Дело в том, что тестирование очень часто находит ошибки в новой фиче, что вызывает еще один цикл исправлений (дополнительный Dev Effort), и еще один цикл тестирования/перетестирования. И чем больше объем тестирования конкретной фичи, тем дольше цикл перетестирования. А чем более сложная фича (не равно емкости Dev Effort), тем больше циклов исправлений и перетестирования ожидается.
Можно предложить укладывать циклы тестирования и перетестирования в изначальный Dev Effort в Story Points, но Capacity команды Тестирования не входит в команду Dev, поэтому так не получится.
Поэтому мы решили попробовать следующий подход. Команда тестирования на стадии прототипирования фичи (до начала разработки), пишет предварительные тесты для покрытия этой фичи, и должна давать отдельную оценку Test Effort, включающую риски по возможным багам, и их переработкой.
Чтобы эту оценку не путать и не складывать с Dev Effort, мы решили сделать ее не цифровой, а символьной, в размерах маек S, M, L, XL.
Мы долго думали, должна ли шкала оценки быть нелинейной (фибоначи например), как Dev Effort в Story Points. И решили, что в этом не необходимости. Дело в том, что заказчик (PM), хочет знать, когда он получит фичу в Прод, и при планировании спринта у него есть выбор, состоящий из Dev Effort и Test Effort, который либо "влазит" в спринт, либо нет. Тогда при планировании сразу понятно, что с большой вероятностью будет доставлена, а что потребует больше одного спринта.
Получилась вот такая схема:
Прогноз усилий по тестированию в размерах маек
То есть, чтобы впихнуть L фичу, надо отдать ее тестировщикам в конце первой недели спринта. Для M, S во вторник, четверг второй недели соотеcтвенно. Для XL зарелизить в рамках одного спринта шансов нет!
А как у Вас с этой проблемой?
