Критерий приёмки иногда приходится менять. Запрет касается не изменений вообще, а незаметной подмены правил после появления результата.
Есть два разных случая.
В первом команда узнала новый факт. Например, поставщик сообщил, что повторный запрос может прийти через сутки, хотя первоначально ожидалось пять минут. Старый критерий больше не соответствует условиям интеграции. Команда фиксирует причину, выпускает новую версию критерия и пересматривает зависящие от него спецификации, тесты и реализацию.
Во втором результат не проходит согласованную проверку. Вместо доработки команда ослабляет условие: увеличивает допустимое время, исключает неудобный сценарий или объявляет частичный результат достаточным. Формально задача становится зелёной, но команда подобрала правило под готовый ответ.
Та же проблема возникает не только с числовыми порогами. Представим форму заявки, для которой команда заранее записала критерий: пользователь получает письмо со ссылкой и может скачать файл. После запуска выяснилось, что система сохраняет адрес, но не отправляет письмо. Если заменить критерий на «контакт появился в базе», команда не уточнит требование, а зачтёт другой пользовательский исход. Новый факт здесь отсутствует. Есть результат, который не прошёл старое правило.
Различить обновление и подмену помогает история версий. Для каждого изменения команда записывает:
• дату и автора; • новый факт или принятое решение; • старую и новую формулировки; • затронутые спецификации, тесты и части реализации; • границу применимости новой версии; • правило переоценки уже полученных результатов.
Граница применимости особенно важна. Команда оценивает старый запуск по критерию, действовавшему в момент запуска. Если новый факт делает старый критерий неверным, журнал сохраняет это основание отдельно. Для следующей версии работы команда применяет новый критерий и обновлённые тесты. Старый результат не становится принятым автоматически только потому, что правило позже изменилось.
Такой протокол не запрещает учиться по ходу проекта. Он отделяет новое знание от попытки объяснить задним числом, почему готовый результат следует засчитать. Команда может изменить критерий, но должна показать основание, область действия и все материалы, которые после этого требуют пересмотра.
