Приемка итерационного проекта при уточнении требований

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

Если требования уточняются, это не означает, что приемка становится бесконечной. Уточнения нужно разделять: что входит в текущий этап, что является дефектом, что становится замечанием, а что уходит в backlog или change request.

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

Такой подход нужен, когда проект развивается по шагам, а не поставляется как один полностью описанный продукт.

Он особенно полезен, если:

• требования уточняются по мере демонстраций;
• MVP запускается раньше полного продукта;
• есть несколько групп пользователей;
• часть интеграций проверяется в процессе;
• заказчик хочет видеть результат до финального релиза;
• проект зависит от решений по приоритетам.

Итерационная приемка не отменяет дисциплину. Наоборот, она требует ясных критериев для каждого этапа.

Приемка по полному ТЗ обычно проверяет заранее описанный объем целиком. Итерационная приемка проверяет согласованный результат конкретного этапа.

Это значит:

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

Критерии готовности отвечают на вопрос: по каким признакам участники поймут, что этап можно принять.

Они могут включать:

• выполненные пользовательские сценарии;
• роли и права;
• обработку основных ошибок;
• результаты тестирования;
• доступность среды;
• документы или инструкции;
• ограничения, которые явно известны и приняты;
• список замечаний, которые не блокируют приемку.

Критерии нужно согласовать до проверки, а не придумывать после демо. Если нужно расписать проверку на уровне отдельной задачи, используйте критерии приемки задачи: основной сценарий, negative cases и способ проверки.

Приемка проходит спокойнее, если критерии появились еще при постановке задач. Отдельно проверьте, как формулировать задачи с проверяемыми критериями приемки, чтобы замечания не превращались в спор о первоначальном scope. Для команды также полезно заранее различить Definition of Ready, Acceptance Criteria и Definition of Done: что можно начинать, что принимать в задаче и при каком общем качестве работа считается завершенной.

Демо должно показывать не "что команда сделала вообще", а согласованные сценарии этапа.

Перед демо полезно подготовить:

• список сценариев;
• тестовые данные;
• роли участников;
• ожидаемый результат;
• известные ограничения;
• список вопросов, которые нужно решить.

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

Дефект - это когда согласованное поведение не работает. Например, заявка должна сохраняться, но не сохраняется.

Уточнение - это детализация уже согласованного поведения. Например, нужно поменять текст статуса или порядок полей.

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

Дефекты исправляются в рамках качества результата. Новые требования оцениваются отдельно и попадают в backlog или change request.

Backlog замечаний должен помогать закрывать этап, а не бесконечно держать его открытым.

В каждой записи стоит указать:

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

Если у замечания нет типа, владельца и решения, оно быстро превращается в спор.

Если замечаний много, для них нужны те же правила, что и для обычного backlog задач: тип записи, владелец, приоритет, связь с критерием приемки и решение, входит ли работа в текущий этап.

• Принимать итерационный проект как один большой финальный релиз.
• Не согласовать критерии готовности до проверки.
• Смешивать дефекты, уточнения и новые требования.
• Блокировать приемку этапа из-за идей для будущего релиза.
• Не закрывать этапы формально.
• Копить замечания без приоритета и владельца.
• Не связывать новые требования с change request.

Команда показывает MVP кабинета дилера: вход, создание заявки, просмотр статуса и очередь менеджера.

На демо появляются замечания:

• заявка не сохраняется при пустом обязательном поле - это дефект;
• нужно поменять название статуса - это уточнение;
• нужен отчет по просроченным заявкам - это новое требование;
• ERP иногда не отдает остатки - это внешний риск или вопрос к интеграции.

Эти пункты нельзя складывать в один список "не принято". Дефект исправляется, уточнение согласуется, отчет уходит в backlog или change request, а интеграционный риск получает отдельного владельца.

Что принимать на каждой итерации?

Согласованный результат этапа: сценарии, критерии готовности, известные ограничения, дефекты и решения по замечаниям.

Можно ли принимать проект, если требования еще уточняются?

Да, если принимается конкретный этап с понятными критериями. Уточнения будущих этапов не должны автоматически блокировать текущий результат.

Чем дефект отличается от нового требования?

Дефект нарушает уже согласованный результат. Новое требование расширяет результат и требует отдельного решения по scope, срокам и бюджету.

Что делать с замечаниями после демо?

Классифицировать, назначить владельца, определить приоритет и решить: исправлять сейчас, вынести в следующий этап, оформить change request или отклонить.

Как связать приемку с change request?

Если замечание меняет согласованный scope или критерии результата, оно должно пройти через change request или отдельное согласование.