Хорошее требование, user story и acceptance criteria

Как выглядит хорошее требование, чем user story отличается от требования и что писать в acceptance criteria.

User story — это не формат требования, а напоминание о разговоре: кто, что хочет и зачем. Требованием её делают acceptance criteria — проверяемые условия приёмки.

Вопрос 1. По каким критериям вы оцениваете качество требования?

Что проверяют. Есть ли у вас чек-лист в голове. Хороший ответ — 5–7 свойств с пояснением, зачем каждое.

• Однозначность. Формулировку нельзя понять двумя способами. Враги однозначности — «и/или», «при необходимости», «соответствующий», «оптимальный».
• Проверяемость. Можно придумать тест, который даёт однозначный ответ «выполнено / не выполнено».
• Полнота. Описан не только основной сценарий, но и границы: пустые значения, максимумы, отказы.
• Непротиворечивость. Не конфликтует с другими требованиями документа.
• Необходимость. За требованием стоит реальная потребность, а не «пусть будет».
• Реализуемость. Выполнимо в рамках технологий, сроков и бюджета.
• Атомарность. Одно требование — одна мысль. Иначе половину нельзя принять.
• Трассируемость. Видно, из какой цели или нормы оно выросло и какой код и тесты его закрывают.

Покажите на примере — это ценится выше списка терминов:

ПЛОХО: Система должна корректно обрабатывать заказы
       и при необходимости уведомлять пользователя.

Почему плохо: «корректно» — неизмеримо; «при необходимости» —
неизвестно, при какой; два требования склеены в одно;
не сказано, каким каналом уведомлять.

ХОРОШО:
R-101. При переходе заказа в статус «Отгружен» система
       отправляет клиенту email на адрес из профиля
       в течение 5 минут.
R-102. Если email в профиле отсутствует, уведомление
       не отправляется, а в журнале заказа делается
       запись «уведомление пропущено: нет email».

Вопрос 2. Чем user story отличается от требования и что такое acceptance criteria?

Что проверяют. Понимаете ли вы, что история — это единица планирования и разговора, а не документация. Кандидаты часто считают, что «мы работаем по Agile, поэтому требований не пишем» — это красный флаг.

Классический шаблон истории: Как <роль>, я хочу <действие>, чтобы <ценность>. Ценность в конце — не украшение: именно она позволяет отбросить историю или предложить более дешёвый способ достичь того же.

Acceptance criteria — условия, при которых команда и заказчик согласны считать историю сделанной. Два рабочих формата:

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

Acceptance criteria (список условий):
1. Кнопка «Отменить» доступна для заказов в статусах
   «Новый» и «Оплачен».
2. Для статусов «В сборке», «Отгружен», «Доставлен»
   кнопка недоступна.
3. При отмене оплаченного заказа создаётся заявка на возврат.
4. Отмена фиксируется в журнале: кто, когда, причина.
5. Причина отмены обязательна, минимум 10 символов.

Второй формат — Gherkin, он же Given/When/Then. Удобен, когда важна последовательность шагов, и напрямую ложится в автотесты:

Scenario: Отмена оплаченного заказа
  Given заказ №1024 в статусе «Оплачен»
  And пользователь имеет роль «Менеджер склада»
  When пользователь отменяет заказ с причиной «клиент передумал»
  Then заказ переходит в статус «Отменён»
  And создаётся заявка на возврат на полную сумму заказа
  And в журнале появляется запись об отмене

Scenario: Попытка отменить отгруженный заказ
  Given заказ №1025 в статусе «Отгружен»
  When пользователь открывает карточку заказа
  Then кнопка «Отменить» недоступна
  And подсказка объясняет: отмена возможна до отгрузки

Правило INVEST помогает оценить саму историю: Independent (не зависит от других), Negotiable (обсуждаема), Valuable (ценна для пользователя), Estimable (оцениваема), Small (влезает в спринт), Testable (проверяема).

Вопрос 3. Два стейкхолдера требуют противоположного. Ваши действия?

Что проверяют. Не побежите ли вы «спрашивать у начальства» и умеете ли вы работать с конфликтом по существу.

Порядок действий, который стоит проговорить:

1. Зафиксировать конфликт письменно — оба требования рядом, с указанием авторов. Часто на этом шаге выясняется, что противоречия нет, а есть разные слова об одном.
2. Вскрыть потребность за каждым. Финансовый контролёр хочет обязательное согласование каждой скидки, продавец — мгновенное оформление. Настоящие потребности: контроль убытков и скорость сделки. Они не противоречат.
3. Найти решение, закрывающее обе потребности. Например: скидка до 5% — без согласования, свыше — согласование с уведомлением в течение часа, отчёт по всем скидкам контролёру ежедневно.
4. Если совместить нельзя — вынести решение на владельца продукта с подготовленными вариантами, их стоимостью и последствиями. Аналитик готовит выбор, а не принимает его за бизнес.
5. Записать решение и того, кто его принял. Через полгода спросят именно об этом.

Типичные ошибки кандидатов

• Считают, что user story заменяет спецификацию. История без критериев приёмки не является требованием.
• Пишут в acceptance criteria интерфейсные мелочи вместо условий приёмки: «кнопка синяя, справа сверху».
• Описывают только happy path — приёмка потом упирается в необработанные случаи.
• Решают конфликт стейкхолдеров «по старшинству должности», не разобравшись в потребностях.
• Забывают про трассируемость: через год никто не может ответить, зачем в системе появилась эта проверка.

Как ответить кратко

Хорошее требование однозначно, проверяемо, атомарно, необходимо, непротиворечиво и трассируемо — то есть по нему можно написать тест и понять, откуда оно взялось. User story — это не требование, а формат разговора «кто, что, зачем»; требованием её делают acceptance criteria: список условий приёмки или сценарии Given/When/Then, обязательно с негативными случаями. Конфликт стейкхолдеров решаю не по должностям: фиксирую оба требования письменно, вскрываю потребность за каждым, ищу решение, закрывающее обе, а если это невозможно — приношу владельцу продукта варианты с последствиями и фиксирую, кто принял решение.