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

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

Max Rehkopf Max Rehkopf
Просмотр тем

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

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

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

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

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

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

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

Пользовательские истории изящно вписываются в методики agile, такие как scrum и kanban. В scrum пользовательские истории добавляют в спринты и отслеживают на burndown-диаграммах в течение спринта. Команды, работающие по методике kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так scrum-команды совершенствуют свои навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут далее совершенствовать свои рабочие процессы.

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

Подробнее об эпиках и инициативах

Эпики, истории и темы в agile | Atlassian — тренер по agile

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

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

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

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

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

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

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

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

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

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

  • Критерии готовности работы. Как правило, история считается «выполненной», когда пользователь может сделать то, что было запрошено. Тем не менее, четко сформулируйте цель.
     
  • Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.
     
  • Типы пользователей. Для кого? При наличии нескольких типов конечных пользователей желательно написать несколько историй.
     
  • Этапы как часть цепи. Напишите историю для каждого этапа, составляющего более масштабный процесс.
     
  • Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?
     
  • Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, поэтому истории, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше. Как вариант, считайте их самостоятельными эпиками.
     

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

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

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

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

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

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

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

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

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

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

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

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

продолжение темы
Estimation