Майк Кон, автор книги ”Пользовательские истории: гибкая разработка программного обеспечения”, выложил для подписчиков своего блога богатый материал. Это статья о пользовательских историях (источник) и примеры историй, которые описывают функциональность ранней версии сайта Scrum Alliance. Делюсь с вами статьей и частью материала.
Что такое пользовательская история?
Пользовательская история - это краткое, простое описание функции, представленное с точки зрения человека, которому необходима новая возможность, обычно пользователя или клиента системы. Пользовательские истории обычно следуют простому шаблону:
Как <тип пользователя>, я хочу <некая цель>, чтобы <некая причина>.
Исторически пользовательские истории намеренно оставляли неформальными, писали на карточках или стикерах и размещали на стенах или столах для облегчения планирования и обсуждения. Их недолговечность позволяла легко разрывать их, выбрасывать и заменять новыми историями по мере того, как становилось больше известно о разрабатываемом продукте.
Сегодня пользовательские истории с таким же успехом могут храниться в задаче Jira или на доске Trello, но это не повод хранить истории, когда они больше не нужны!
Пользовательские истории призваны сильно сместить фoкус с написания деталей функций на их обсуждение. Фактически, эти обсуждения важнее любого написанного текста.
Что такое хорошая пользовательская история?
Гибкие пользовательские истории состоят из трех аспектов, которые Рон Джеффрис назвал в 2001 году замечательной аллитерацией: карточка, беседа и подтверждение (card, conversation, confirmation):
- Карточка: Письменное описание истории, используемое для планирования и как напоминание.
- Беседа: Обсуждения истории, которые служат для детализации истории.
- Подтверждение: Тесты, которые передают и документируют детали, позволяющие определить, когда история завершена.
У пользовательских историй много преимуществ, но самое важное, пожалуй, заключается в том, что каждая пользовательская история - это место для будущей беседы.
Как писать пользовательскую историю?
Написание хороших пользовательских историй в Scrum требует понимания базового шаблона пользовательской истории, фокуса на пользователе или клиенте и четкого представления о желаемой функциональности.
Шаблон пользовательской истории
При написании пользовательской истории помните, что они следуют стандартному шаблону:
Как <КТО>, я хочу <ЧТО>, чтобы <ПОЧЕМУ>.
Примеры пользовательских историй
Один из лучших способов научиться писать пользовательские истории в Agile - это посмотреть на примеры. Вот несколько реальных примеров пользовательских историй, описывающих желаемую функциональность в ранней версии веб-сайта Scrum Alliance.
- Как участник команды, я могу заполнить заявку на сертификацию Scrum-тренера (CST), чтобы я мог преподавать курсы Certified Scrum Master (CSM) и Certified Scrum Product Owner (CSPO) и сертифицировать других.
- Как тренер, я хочу, чтобы в моем профиле отображались мои предстоящие занятия и была ссылка на подробную страницу о каждом из них, чтобы потенциальные слушатели могли найти мои курсы.
- Как посетитель сайта, я могу получить доступ к старым новостям, которых больше нет на главной странице, чтобы я мог найти то, что помню из прошлого или о чем мне говорили другие.
- Как пользователь сайта, я могу видеть список всех предстоящих «сертификационных курсов» и пролистывать его, если их много, чтобы я мог выбрать лучший для себя курс.
Обратите внимание, что здесь нет истории вроде: «Как владелец продукта, я хочу список сертификационных курсов, чтобы...». Владелец продукта - важная заинтересованная сторона, но не конечный пользователь или клиент. При создании пользовательских историй лучше быть как можно более конкретным в отношении типа пользователя.
Кто пишет пользовательские истории?
Кто пишет пользовательские истории? Писать пользовательские истории может кто угодно.
Пишет ли пользовательские истории владелец продукта? Владелец продукта несет ответственность за управление бэклогом продукта, но это не значит, что именно он их пишет. В Agile пользовательские истории могут быть написаны написаны любым членом команды. Не так важно, кто пишет пользовательскую историю. Важнее, кто участвует в ее обсуждениях.
Когда пишутся пользовательские истории?
Пользовательские истории пишутся на протяжении всего Agile-проекта. Обычно воркшоп по написанию историй проводится в начале Agile-проекта. Каждый участник команды участвует в нем с целью создания бэклога продукта, который полностью описывает функциональность, которая будет добавлена в ходе проекта или в рамках его трех-шестимесячного цикла релиза.
Одним из преимуществ пользовательских историй является то, что они могут быть написаны с разным уровнем детализации. Мы можем написать пользовательскую историю, охватывающую большие объемы функциональности, или только небольшую отдельную функцию. Крупные пользовательские истории менее детализированы и обычно называются эпиками.
Некоторые из этих пользовательских историй, будут эпиками. Эпики позже будут разбиты на более мелкие истории, которые легче умещаются в одну итерацию. Кроме того, новые истории могут быть написаны и добавлены в бэклог продукта в любое время и кем угодно.
Вот несколько типичных пользовательских историй для сайта по размещению вакансий и поиску работы:
- Пользователь может разместить свое резюме на веб-сайте.
- Пользователь может искать вакансии.
- Компания может публиковать новые вакансии.
- Пользователь может ограничить круг лиц, которые могут видеть его резюме.
Пример эпика для продукта резервного копирования рабочего стола:
Как пользователь, я могу сделать резервную копию всего моего жесткого диска.
Поскольку эпик обычно слишком велик для гибкой команды, чтобы выполнить его за одну итерацию, перед началом работы он разбивается на несколько более мелких пользовательских историй. Приведенный выше эпик можно разбить на десятки (а возможно, и сотни) историй, например такие:
- Как опытный пользователь, я могу указать файлы или папки для резервного копирования на основе размера файла, даты создания и даты изменения.
- Как пользователь, я могу указать папки, которые не нужно копировать, чтобы мой диск для резервного копирования не заполнялся тем, что мне не нужно сохранять.
Как добавляется детализация в пользовательские истории?
Детализация может быть добавлена в пользовательские истории двумя способами:
- Разделением пользовательской истории на несколько более мелких пользовательских историй.
- Добавлением критериев приемки.
Критерии приемки - это просто высокоуровневый приемочный тест, который должен быть успешным после реализации пользовательской истории. Рассмотрим следующий пример гибкой пользовательской истории:
Как вице-президент по маркетингу, я хочу выбирать праздничный сезон для анализа эффективности прошлых рекламных кампаний, чтобы определять прибыльные из них.
Детализацию можно дополнить такими критериями приемки:
- Убедиться, что это работает для основных розничных праздников: Рождество, Пасха, День президентов, День матери, День отца, День труда, Новый год.
- Поддержка праздников, которые охватывают два календарных года (ни один не охватывает три).
- Праздничные сезоны могут быть установлены от одного праздника до другого (например, от Дня благодарения до Рождества).
- Праздничные сезоны могут быть установлены за определенное количество дней до праздника.
Заменяют ли пользовательские истории документы с требованиями?
В Agile-проектах, особенно в Scrum, бэклог представляет собой приоритезированный список функций, подлежащих разработке. Элементы бэклога продукта могут быть любыми, какими пожелает команда, но пользовательские истории выглядят наиболее подходящей формой.
Важно помнить, что письменная часть гибкой пользовательской истории («Как пользователь, я хочу...») является неполной до тех пор, пока не состоятся обсуждения этой истории.
Лучше всего думать о письменной части как об указателе на реальное требование. Пользовательские истории могут указывать на диаграмму, изображающую рабочий процесс, таблицу, показывающую, как выполнить расчет, или любой другой артефакт, который пожелает владелец продукта или команда.
Примеры пользовательских историй
В дополнение статьи - посмотрите примеры разных пользовательских историй от Майка Кона в нашем сообществе в ВКонтакте. Эти примеры пользовательских историй описывают функциональность ранней версии сайта Scrum Alliance. Они были созданы в начале 2004 года. Автор прокомментировал так: «Некоторые из них хорошие, некоторые не очень. Не смотря на это я даю полный набор, как демонстрацию того, что я считал тогда подходящим началом бэклога продукта для этого сайта.»