Готово или НЕ готово — вот в чем вопрос 🤔
В прошлом посте мы научились писать идеальные User Stories, фокусируясь на том, ЗАЧЕМ мы что-то делаем. Теперь настало время ответить на самый важный вопрос: как мы узнаем, что фича действительно готова?
❓Что такое критерии приемки и почему они важны?
Acceptance Criteria (Критерии Приемки) — это четкий, измеримый и бинарный (ДА/НЕТ) список условий, которые должны быть выполнены, чтобы заказчик или QA сказал: “Принято. Задача завершена.”
AC — это не "советы по реализации". Это границы качества. Они не говорят разработчику, на каком фреймворке писать код, но они абсолютно точно говорят ему, какой результат он должен получить.
💡 Почему AC критически важны для аналитика и разработчика:
🔴AC превращают расплывчатое "быстро" в измеримое "не более 2 секунд".
🔴Каждый критерий — это потенциальный тест-кейс. Если AC нет, QA не знает, что именно проверять.
🔴Они фиксируют объем работы. Если в процессе разработки появляется идея "а давайте еще это…", мы всегда можем сослаться на утвержденные AC.
✏️ Как писать AC, чтобы они работали? (формат GIVEN-WHEN-THEN)
Самый надежный способ фиксации AC — это формат GIVEN-WHEN-THEN (дано-когда-тогда).
User Story: как зарегистрированный пользователь, я хочу иметь возможность сбросить пароль через email, чтобы восстановить доступ к аккаунту.
Плохие AC:
❌Система должна прислать письмо.
❌Ссылка должна работать.
Хорошие AC (GIVEN-WHEN-THEN):
✔️Сценарий: успешный сброс
GIVEN: пользователь ввел существующий email и нажал "Забыли пароль".
WHEN: Система отправляет письмо со ссылкой.
THEN: В логах появляется запись об отправке, а пользователь видит сообщение: "Инструкции отправлены на вашу почту."
🚩 Главный вывод
Не отдавайте User Story в разработку, пока команда (особенно QA) не согласует полный и исчерпывающий список Acceptance Criteria. AC — это гарантия того, что вы не просто потратили время, а создали нужный, рабочий продукт.
#статьи_WBS #userstory #системныйаналитик
