Планируешь ли пересматривать оценки задач

Что проверяют

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

Как отвечать

Да, пересматриваю, и назовите поводы. Для тестирования они обычно такие:

• выросла область регресса: правка задела общий модуль, и вместо одного сценария нужен прогон смежных;
• стенд или данные оказались не готовы, время уходит на подготовку, а не на проверки;
• в первой же итерации найдено много дефектов: перепроверка после починки это отдельный объём, который в первую оценку почти никогда не заложен;
• требование уточнилось по ходу, появились новые состояния и граничные случаи.

Дальше про форму. Оценка даётся диапазоном или с явным допущением, а не точкой: «два дня, если тестовые данные готовы к понедельнику». Пересмотр озвучивается тогда, когда стало понятно, а не в день сдачи. И оформляется он не как «не успеваю», а как выбор: что вынести из объёма, что проверить поверхностно, чем рискуем, если релиз всё равно едет по плану. Раз в несколько спринтов полезно сверять оценки с фактом: обычно недооценивают не написание проверок, а ретест и переписку по дефектам.

Где спотыкаются

Называют выдуманный процент улучшения планирования. Точность оценок почти нигде не измеряют, и цифра вроде «стали точнее на двадцать процентов» тянет за собой вопрос, чем мерили и что было базой, на котором ответ рассыпается.

Вторая ошибка: пересматривать оценку молча и в последний день. Смысл пересмотра в том, что он даёт время на решение. Сообщённый постфактум, он перестаёт быть пересмотром и становится сорванным сроком.

Третья: путать оценку и дедлайн. Когда на вопрос «сколько нужно» кандидат отвечает «сколько надо, столько и сделаем», команда теряет единственный инструмент планирования, а тестирование по факту сжимается до остатка спринта.