Пользовательские истории и критерии приёмки: как ясно формулировать требования

Коротко: Пользовательская история описывает требование с точки зрения пользователя одним предложением; критерии приёмки определяют, когда оно считается выполненным.

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

Подробности

Формат

Как <роль> я хочу <функция>, чтобы <польза>. Пример: «Как клиент я хочу получать подтверждение заказа по электронной почте, чтобы знать, что он дошёл.» Три части отвечают на вопросы Кто? Что? Зачем? «Чтобы» предотвращает функции без цели. История — не полный договор, а повод для разговора.

Хорошие истории: INVEST

• Independent (независимая)
• Negotiable (обсуждаемая)
• Valuable (ценная для пользователя/клиента)
• Estimable (оцениваемая)
• Small (достаточно малая для спринта)
• Testable (тестируемая) Слишком крупные истории («эпики») делят на меньшие.

Критерии приёмки

Они конкретно описывают, когда история готова, в идеале в формате given – when – then:

• Given корзина не пуста, when я плачу, then я получаю письмо с подтверждением и номером заказа.
• Письмо приходит в течение 5 минут; содержит товары, итог, адрес доставки.
• При недопустимом адресе электронной почты показывается сообщение об ошибке. Они тестируемы (да/нет), достаточно полны и составляют основу тестов (см. BDD) и приёмки.

Встраивание в проект

Истории находятся в бэклоге продукта, приоритизируются и реализуются в спринте. Определение готовности (DoD) действует для всех историй (код проверен, тесты зелёные, документировано, развёрнуто), критерии приёмки — для одной истории. В документации IHK можно представлять требования как пользовательские истории с критериями и дополнять документами требований/технического задания. Дополнительно: диаграммы вариантов использования, прототипы, эскизы.

См. также: Гибкие методы, Документы требований и технического задания, BDD, Приёмка и передача