User stories и критерии приёмки

User Story — это короткая формулировка намерения пользователя, которая описывает, что конкретная роль хочет достичь и как это поможет. Формула истории пользователя звучит так: 'Как <роль>, я хочу <действие>, чтобы <выгода>'. Популяризована Mike Cohn (XP/Scrum), и сегодня история пользователя является важным инструментом для коммуникации между командой разработчиков и пользователями. Она служит не только для описания функциональности продукта, но и для стимулирования диалога, который помогает уточнить требования и выявить скрытые предположения.

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

Как это работает

Card: История пользователя обычно записывается на маленькой карточке или тикете. Это позволяет избежать преждевременного детализирования и сохраняет фокус на ключевых элементах истории. Conversation: Business Analyst (BA), Product Owner (PO), разработчики и (если это возможно) реальные пользователи обсуждают историю пользователя до начала разработки. Это помогает выявить скрытые предположения и убедиться, что команда правильно понимает требования. Confirmation: Критерии приёмки специфицируют, как команда узнает, что история пользователя готова. Формат истории пользователя — 'Как X, я хочу Y, чтобы Z' — помогает явно артикулировать, кто, что и почему именно в этом порядке.

Когда применять

User stories лучше всего работают в продуктовых командах, где есть регулярный доступ к стейкхолдерам, и где разговоры о требованиях могут реально происходить. Они особенно эффективны в контексте Agile методологии, где регулярные итерации позволяют быстро адаптироваться к изменениям. Однако, когда контрактная передача требует самодостаточных спецификаций, использование формальных требований может быть более подходящим. Также, когда работа чисто техническая, например, рефакторинг базы данных, где нет реального пользователя, использование задач (tasks) может быть более релевантным. Наконец, если команда слишком большая, чтобы все могли разделять контекст, её следует разделить на меньшие команды.

Типичные ошибки

(1) Story-as-spec — написание истории пользователя настолько детальной, что она покрывает каждый edge case в тексте карточки. Это приводит к тому, что никто не читает её, так как она становится слишком сложной и трудной для понимания. Вместо этого следует держать карточку короткой, а детали переносить в критерии приёмки. (2) 'Как пользователь, я хочу X' — каждый пользователь хочет каждую фичу, но это не всегда верно. Спецификация конкретной роли помогает уточнить, кто именно хочет данную фичу. (3) Нет 'чтобы' — без выгоды историю пользователя нельзя депризиритизировать против альтернатив; это приводит к тому, что команда строит не то, что было запланировано.

Связанные понятия

• Story Format (INVEST)
• Acceptance Criteria
• Story Mapping