Основная причина, по которой большинство проектов переходят на Agile, в том, что они хотят видеть быстрый результат. Но результаты не могут достигаться быстро, если нет ясных ожиданий и требований. Для этого хорошо работают пользовательские истории.
User stories содержат минимальные бизнес-требования, которые показывают, для кого и для чего нужно разработать новую функциональность. В Agile-подходах требования часто выражаются в этом формате из-за краткости и внимания на клиенте. В этой статье мы дадим несколько советов, которые помогут лучше понять пользовательские истории и заставят их работать.
Кто владеет пользовательской историей?
Чтобы не было путаницы, кто несёт ответственность за User Stories, — это владелец продукта. Кто может их написать? Любой, кто понимает требования и может рассказать детали. Если в команде есть бизнес-аналитик или команда достаточно подключена к работе с бэклогом, оформление историй может быть делегировано. Но в конце концов, владелец продукта должен просмотреть и принять новые US.
- Создание историй можно делегировать.
Анатомия User Story
Пользовательская история, согласно классическому шаблону, имеет следующие элементы:
- роль,
- действие,
- намерение, цель/желание.
Строгая структура помогает добиться единообразия: ни один из компонентов шаблона не пропускается. Но стоит помнить, что не все задачи подходят под формат пользовательских историй. Нефункциональные требования, очевидные задачи или технические истории часто не ложатся на шаблон истории.
- Не пытайтесь натянуть требования под формат User Story, если итог теряет здравый смысл.
Апдейт User Story
Существуют еще несколько атрибутов пользовательских историй, которые делают их использование более удобным:
- уникальный номер, чтобы облегчить поиск истории,
- система тегов для всех элементов бэклога, чтобы быстро выбирать истории на одну тему/область работы, под цель спринта,
- критерии приёмки — фактическое описание того, что ожидается получить после разработки, чтобы считать работу сделанной,
- зафиксированные даты: от попадания в бэклог до релиза, по основным точкам. Это помогает отследить рабочий поток и некоторые другие метрики,
- оценка работы — до начала работы над историей можно оценить бэклог, например, по методу Magic Estimation. Это позволит примерно соотнести бизнес-ценность и трудозатраты,
- бизнес-ценность с точки зрения получения или потерь денег, репутации и других факторов.
Написание пользовательских историй
Пользовательская история должна быть краткой. Её основное назначение — вызвать обсуждение. Не пытайтесь учесть всё заранее. Критерии приёмки и другие атрибуты можно создать вместе с командой. Дополнительные детали прикрепить в виде интеллект-карт или фотографий с белой доски.
Хорошая пользовательская история написана в активном залоге и занимает одну-три строчки.
- Не тратьте излишне много времени на написание истории. Лучше идите и обсудите её.
Управление пользовательскими историями
Требования в гибких проектах являются предметом разговора. Их можно обсуждать и модифицировать до тех пор, пока они не попадут в спринт. И даже тогда они могут меняться. Чтобы не запутаться в изменениях, важно иметь общедоступную версию бэклога. Это может быть в Jira, VersionOne, Trello, Rally, Kaiten и т. д. Не ограничивайте доступ к доске только командой и стейкхолдерами. Бэклог — прозрачен для всех.
Детализация User Story происходит по принципу 3C, в три этапа:
- запись — на карточку записывается история в общем виде, без значительных деталей,
- обсуждение — команда обсуждает функциональность, детализирует карточку, в итоге участники дают оценку трудозатрат, а PO пишет ценность,
- подтверждение — последний этап, когда добавляются критерии приёмки и тест-кейсы, которые необходимо пройти, чтобы считать историю выполненной.
Проверяйте на соответствие INVEST
Хорошая практика, когда пользовательские истории в Scrum соответствуют INVEST:
- «I» независимая (от всех остальных),
- «N» обсуждаемая (не конкретный контракт для функций),
- «V» ценная (обеспечивает ценность для конечного пользователя),
- «Е» оцениваемая (в хорошем приближении),
- «S» маленькая (чтобы вмещаться в итерацию),
- «Т» тестируемая (в целом, даже если тесты ещё не написаны).
Пользовательские истории служат началом дискуссии, поэтому они работают в проектах, где владелец продукта доступен для обсуждения. Если это условие не выполняется, то команде может подойти другой формат записи требований.
