User Stories – что это, для чего и можно ли обойтись без них?

Истории пользователей, или user story, – это часть аджайл-подхода, которая помогает перефокусировать внимание с написания на обсуждение требований. Каждая история состоит из одного, максимум двух предложений. Ее задача – поднять обсуждение фичей и функциональности, которые эта история представляет.

Пользовательская история – это способ описать необходимую функциональность элементов продуктового беклога. Высокоприоритетные user story обычно лучше детализированы; низкоприоритетные – хуже. Больше деталей команды добавляют с возрастанием приоритетности истории – либо создавая критерии приемки (acceptance criteria), либо разделяя большие истории на маленькие. Либо и то, и другое.

Ниже мы расскажем больше о user story, шаблонах их написания, а также покажем несколько примеров.

Перевод статьи Майка Кона осуществлен для вас командой BrainRain.

Что такое user story?

История пользователя (юзер стори, user story) – это сжатое, простое описание фичи, изложенное с точки зрения человека, которому нужен новый функционал. Обычно это – пользователь или заказчик системы. User story пишутся по простому шаблону:

Как < тип пользователя >, я хочу < цель >, чтобы < причина >.

Исторически user сторі специально выглядели максимально неформально: написанные на стикерах, сложенные в коробку из-под обуви, прицепленные к стенам для фасилитации планирования и обсуждений. Благодаря этому их было легко и не жалко рвать, выбрасывать и менять на новые, когда появлялось больше информации о продукте.

Сегодня пользовательские истории так же легко складировать в задачи Jira или карточки Trello. Но не позволяйте тому факту, что юзер стори живет внутри инструмента, сбивать вас с толку. Удаляйте ее легко и навсегда, когда user story станет неактуальной!

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

Как выглядить хорошая user story?

Agile юзер стори состоят из трех аспектов (трех С), названных Роном Джеффрисом в 2001 году:

1. Card – карточка: письменное описание истории, которое используется для планирования и как напоминание.
2. Conversation – разговор: коммуникация вокруг истории, которая служит для детализации.
3. Confirmation – подтверждение: тесты и документация, которые могут использоваться для определения готовности истории.

У юзер стори множество преимуществ, и главное – то, что каждая история это плейсхолдер для будущего разговора.

Как писать user story

Чтобы писать хорошие истории в Scrum, нужно понимать базовый шаблон user story, фокусироваться на пользователе, а также иметь четкую картину нужной функциональности.

Шаблон user story

Как < тип пользователя >, я хочу < цель >, чтобы < причина >.

Примеры историй пользователей

Это реальные примеры user story, описывающие нужную функциональность ранних версий сайта Scrum Alliance.

• Как зарегистрированный участник сайта, я могу заполнить заявку на получение лицензии Certified Scrum Trainer, чтобы иметь возможность читать курсы Certified Scrum Master (CSM) и Certified Scrum Product Owner (CSPO) и сертифицировать участников этих курсов.
• Как тренер, я хочу, чтобы в моем профиле был список моих ближайших курсов и ссылка на подробную страницу каждого курса, чтобы перспективные участники могли найти мои курсы.
• Как посетитель сайта, я могу видеть старые новости, которые больше не отображаются на главной, чтобы иметь доступ к информации из прошлого или новостей, о которых упоминают другие.
• Как посетитель сайта, я могу видеть перечень всех запланированных сертификационных курсов постранично, если их много, чтобы иметь возможность выбрать подходящий мне курс.

Обратите внимание, что в списке нет такой стори: «Как владелец продукта, я хочу иметь список сертификационных курсов, чтобы…» Владелец продукта – это важный стейкхолдер, но не пользователь. Создавая юзер стори, следует как можно конкретнее описывать тип пользователя.

Кто пишет истории пользователей?

Любой может.

Пишет ли user story Продакт Оунер?

Убедиться, что бэклог продукта актуален и наполнен аджайл юзер стори – задача владельца продукта. Но это не значит, что он должен их все написать. В хорошем аджайл-проекте истории пользователей пишутся каждым членом команды.

Между прочим, автор юзер стори гораздо менее важен, чем участники ее обсуждения.

Когда пишутся истории пользователей?

Истории пользователей пишутся на протяжении всей работы над аджайл-проектом. Обычно воркшоп по написанию историй проводят перед началом проекта. В нем принимают участие все члены команды. Цель – создать продуктовый бэклог, полностью описывающий функциональность, которую необходимо добавлять в бэклог на протяжении релизного цикла длительностью от 3 до 6 месяцев.

Какие-то из этих историй без сомнения станут эпиками. Эпики впоследствии декомпозируются на меньшие стори, которые можно уместить в одну итерацию. Плюс, новые пользовательские истории появляются и добавляются в бэклог на протяжении всего времени работы над продуктом.

А можно более общие примеры историй пользователей?

Конечно, вот, например, типичные юзер стори для сайта размещения вакансий и поиска работы:

• Пользователь может запостить резюме на сайте.
• Пользователь может искать вакансии.
• Компания может выкладывать новые вакансии.
• Пользователь может ограничить, кто видит его резюме.

Примеры эпиков

Одно из преимуществ аджайл-историй – в том, что их можно писать на совершенно разных уровнях сложности. Мы можем делать сторю как для большой группы функциональности, так и для конкретной маленькой фичи.

Большие юзер стори обычно менее детализированы и известны под названием “эпики”.

Вот пример такого эпика с десктопного бэкап-продукта.

• Как пользователь, я могу создать полный бэкап моего жесткого диска.

Поскольку по большей части эпик слишком большой для одной итерации аджайл-команды, прежде, чем работать, поделим его на несколько меньших историй. Эпик, описанный выше, можно разделить хоть на сотню историй, включая такие (в качестве образца):

• Как глубокий пользователь, я могу определять, какие файлы и папки сохранять, основываясь на размере файлов, дате создания и дате последнего изменения.
• Как пользователь, я могу отмечать, чтобы какие-то папки не сохранялись в бэкап, тем самым защищая свой бэкап от информации, хранить которую мне не нужно.

Как детализируются истории пользователей?

Существует два способа добавлять детали в юзер стори:

• Разделяя историю на меньшие;
• Добавляя критерии приемки к user story (acceptance criteria).

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

Критерии приемки – это высокоуровневый тест приемки, который можно будет исполнить после завершения работы над гибкой юзер стори. Рассмотрим следующий пример истории:

• Как вице-президент маркетинга, я хочу провести ревью перфоманса прошлых рекламных кампаний в праздничные периоды, чтобы определить, какие из них принесли прибыль.

Добавим детали с помощью критериев приемки:

• Убедитесь, что самые важные для торговли праздники включены в список: Рождество, Пасха, День Президента, День матери, День отца, День труда, Новый год.
• Включите сюда праздники, которые распространяются на два календарных года.
• Праздничные периоды могут длиться от одного праздника до другого (например, от Дня благодарения до Рождества).
• Праздничные периоды можно устанавливать за некоторое количество дней до наступления праздника.

Могут ли юзер стори заменить требования?

Agile, а особенно Scrum проекты используют бэклог продукта – приоритизированный список функциональности продукта или услуги, ожидающей разработки. Пусть элементы продуктового бэклога могут выглядеть как пожелает команда, юзер стори сегодня – лучшая и самая распространенная их форма.

И пусть продуктовый бэклог можно рассматривать как замену документа с требованиями на традиционном проекте, важно помнить, что написанная часть истории пользователя (“Как пользователь, я хочу…”) не завершена, пока по ней не случилась дискуссия.

Мы советуем воспринимать написанную часть стори как указание на реальные требования. Истории пользователей могут указывать на диаграмму, описывающую процесс, таблицу, где объясняется, как производить расчеты, или любой другой артефакт от ПО или команды.