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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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