Пользовательские истории с примерами и шаблоном

Основные моменты

• Пользовательские истории — короткие описания требований к продукту с точки зрения пользователя. Они укрепляют сотрудничество в Agile-командах и повышают качество продукта.

• Они помогают командам осознать, для чего все делается, и разбить крупные проекты на выполнимые задачи.

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

• Разбейте свой следующий проект на пользовательские истории, чтобы уточнить приоритеты и увлечь команду.

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

Уникальная черта agile-разработки ПО — ставить во главу угла человека, и пользовательские истории как раз служат для того, чтобы в центре обсуждения всегда были фактические пользователи. Истории пишутся простым языком, без технической специфики, и служат контекстом для команды разработчиков и их деятельности.

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

Что такое пользовательские истории в agile?

Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО.

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

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

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

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

Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально управлять незавершенной работой (WIP) и могут в дальнейшем совершенствовать рабочие процессы.

Из пользовательских историй также складываются более крупные элементы методик Agile, такие как эпики и инициативы. Эпики — это большие рабочие задачи, которые делятся на несколько историй. Группа эпиков образует инициативу.

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

Три «О» в концепции пользовательских историй

Три «О» в контексте применения пользовательских историй — это описание, обсуждение и обоснование (или 3 C: Card, Conversation, Confirmation). Участники составляют описание истории, проводят обсуждение, чтобы уточнить детали, и договариваются о критериях приемлемости результатов (обосновании готовности).

Применение этих трех «О» делает пользовательскую историю понятной, доступной для совместной работы и проверяемой. Например, команда может написать историю на карточке, обсудить требования во время уточнения бэклога и согласовать конкретные критерии готовности перед началом работы.

Из чего состоит пользовательская история?

Пользовательская история обычно содержит краткое описание желаемой функциональности, потребностей пользователя и критериев приемки. Стандартный формат: «Как [пользователь], я хочу [цель], чтобы [причина]».

Добавление критериев приемки помогает командам понять, что считать успехом, и гарантирует тестируемость пользовательской истории. Например, история может звучать так: «Как покупатель, я хочу сохранить товары в списке желаний, чтобы купить их позже», — а критерии определяют, как должен работать список желаний.

Как может звучать пользовательская история?

Пример пользовательской истории: «Как руководитель проекта, я хочу сформировать отчет о статусе проекта, чтобы поделиться информацией о прогрессе с заинтересованными сторонами». Эта история отражает пользователя, его цель и получаемую им выгоду.

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

Зачем нужны пользовательские истории?

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

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

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

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

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

Узнайте, как пользовательские истории реализованы в Jira Software

Работа с пользовательскими историями

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

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

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

Как написать пользовательскую историю

При написании пользовательских историй держите в уме следующее.

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

• Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.

• Типы клиентов. Для кого все делается? При наличии нескольких типов конечных пользователей желательно написать несколько историй.

• Последовательность этапов. Напишите историю для каждого этапа более масштабного процесса.

• Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?

• Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, а те, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше или считать самостоятельными эпиками.

Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.

Шаблон и примеры пользовательских историй

Пользовательские истории часто представлены в виде простого предложения следующего вида:

«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».

Давайте разберем эту формулировку.

• «Как [тип клиента]»: для кого мы выполняем эту работу? Нам не так важна должность, сколько личность, что стоит за типом клиента. Вот Макс, например. Нашей команде нужно иметь единое представление о том, что Макс за человек. К счастью, мы опросили множество Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. Мы испытываем к Максу эмпатию.

• «Хочу то-то»: в этой части заключается намерение пользователя — не возможностей, которыми он пользуется. Чего пользователь хочет достичь? В этом утверждении не должно быть ни слова о способах реализации. Если вы описываете какую-либо деталь пользовательского интерфейса, игнорируя цель пользователя, вы упускаете суть.

• «Чтобы делать что-то»: какое место отведено этому сиюминутному желанию клиента в более широком масштабе? Какую пользу в целом хочет извлечь клиент? Какую крупную проблему нужно решить?

Пользовательские истории могут выглядеть, например, следующим образом.

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

• Как Саша, я хочу организовать свою работу, чтобы лучше контролировать ситуацию.

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

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

Начало работы с пользовательскими историями в agile

В пользовательских историях раскрываются суть и цели повседневной работы участников команды разработчиков. Зачастую они написаны в форме «тип клиента + потребность + цель». Чтобы процесс работал как часы, важно понимать роль историй: именно в них объясняется, что должна сделать команда и почему она должна это сделать.

Начните с оценки следующего или самого срочного крупного проекта (например, эпика). Разбейте его на небольшие пользовательские истории и вместе с командой разработчиков доведите до ума. Когда истории будут готовы и представлены на суд всей команды, можно приступать к работе.

Связанные ресурсы

• Ресурсы по управлению проектами

  • Ресурсы по планированию проекта

  • Ресурсы по запуску продукта

  • Стратегии по управлению проектами для выхода на рынок

  • Ресурсы по управлению ресурсами

  • Ресурсы по отслеживанию заданий

  • Ресурсы по управлению маркетинговыми проектами

  • Ресурсы по управлению программами

  • Ресурсы для руководителей проектов

  • Управление проектами по разработке ПО