Одна из ключевых проблем в разработке продуктов — взаимопониманием стейкхолдеров и команды, а также всех участников внутри команды. Один из классных подходов с решением проблемы — формат user story.
В книге «красный скрам», этот термин переводится как «сценарий». Где каждая задача это сценарий, который может биться на более мелкие сценарии или подзадачи.
Сценарии (пользовательские истории, user story) — это быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель сценариев состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира.
Определение из Вики
Пользовательские истории (англ. User Story, вариант перевода Сценарии) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приёмочными испытаниямиruen). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — пишутся либо одобряются ролью владельца продукта (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.
Формат
Хорошо подходит формат user story: «Как <роль>, я хочу делать <это>, чтобы <достигать цели>».
Примеры User Story
- Как Посетитель сайта, я хочу подписаться на интересные для меня продукты, чтобы получать по ним новости и статьи
- Как Владелец Интернет-магазина, я хочу видеть панель управления, чтобы понимать текущее состояние дел и динамику дохода/прибыли
Декомпозиция User Story
Чтобы реализовать задачу типа US, бывает нужно ее декомпозировать.
Можно прописать и структурировать аспекты по задаче. Отлично подходит практика ВИСИ.
Иногда есть смысл сделать ToDo-список по реализации.
А во многих трекерах US можно разбить на подзадачи и отслеживать прогресс выполнения.
