Пользовательские истории - это задачи разработки, часто выражаемые как «персона + потребность + цель».
Заманчиво думать, что пользовательские истории - это, проще говоря, системные требования программного обеспечения. Но это не так.
Ключевой компонент agile разработки программного обеспечения - ставить людей на первое место, а истории пользователей ставят реальных конечных пользователей в центр разговора. Истории используют нетехнический язык, чтобы обеспечить контекст для команды разработчиков и их усилий. После прочтения пользовательской истории команда знает, почему они создают то, что они создают, и какую ценность это имеет.
Пользовательские истории являются одним из основных компонентов agile программы. Они помогают обеспечить ориентированную структуру на пользователя для повседневной работы, которая способствует совместной работе, творчеству и повышению качества продукта в целом.
Что такое Agile пользовательские истории?
Пользовательская история - это самая маленькая единица работы в agile структуре. Это конечная цель, а не функция, выраженная с точки зрения пользователя программного обеспечения.
Цель пользовательской истории состоит в том, чтобы сформулировать, как часть работы предоставит заказчику определенную ценность. Обратите внимание, что «клиенты» не должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними клиентами или коллегами в вашей организации, которые зависят от вашей команды.
Пользовательские истории - это несколько предложений на простом языке, которые обозначают желаемый результат. Они не идут в детали. Требования добавляются позже, после согласования с командой.
Истории вписываются в гибкие фреймворки, такие как scrum и kanban. В scrum пользовательские истории добавляются в спринты и «сгорают» на протяжении всего спринта. Команды kanban помещают пользовательские истории в свои беклоги и запускают их в процессе работы. Именно эта работа над пользовательскими историями помогает командам scrum лучше оценивать и планировать спринты, что приводит к более точному прогнозированию и повышению гибкости. Благодаря историям команды kanban узнают, как управлять работой в процессе (WIP), и могут еще больше усовершенствовать свои рабочие процессы.
Пользовательские истории также являются строительными блоками для более крупных agile фреймворков, таких как эпики и инициативы. Эпики - это большие рабочие элементы, разбитые на ряд историй, а множество эпиков составляют инициативу. Эти более крупные структуры гарантируют, что повседневная работа команды разработчиков (на запасах) вносит вклад в организационные цели, заложенные в эпиках и инициативах.
Зачем создавать пользовательские истории?
Для групп разработчиков, начинающих работать с agile, пользовательские истории иногда кажутся дополнительным шагом. Почему бы просто не разбить большой проект (эпопею) на серию шагов и продолжить его? Но истории дают команде важный контекст и связывают задачи с ценностью, которую приносят эти задачи.
Пользовательские истории служат ряду ключевых преимуществ:
- Истории держат фокус на пользователе. Список «Выполнить» позволяет команде сосредоточиться на задачах, которые необходимо отметить, но коллекция историй позволяет команде сосредоточиться на решении проблем для реальных пользователей.
- Истории позволяют сотрудничество. Определив конечную цель, команда может работать вместе, чтобы решить, как лучше обслуживать пользователя и достичь этой цели.
- Истории движут креативными решениями. Истории побуждают команду критически и творчески думать о том, как наилучшим образом решить поставленную задачу.
- Истории создают импульс. С каждой мимолетной историей команда разработчиков наслаждается небольшими вызывами и небольшой победой, движущей импульсом.
Работа с пользовательскими историями
Как только история написана, пришло время интегрировать ее в ваш рабочий процесс. Как правило, история пишется владельцем продукта, менеджером продукта или менеджером программы и представляется на рассмотрение команде.
Во время встречи по спринту или планированию итераций команда решает, за какие истории они энергично возьмутся в том спринте. Команды теперь обсуждают требования и функциональные возможности, которые требуются для каждой пользовательской истории. Это возможность получить технический и творческий подход к реализации истории команды. После согласования эти требования добавляются к истории.
Другим распространенным шагом на этой встрече является оценка историй на основе их сложности или времени до завершения. Команды используют размеры футболок, последовательность Фибоначчи или планирование покера, чтобы сделать правильные оценки. История должна иметь размеры, чтобы завершить ее в одном спринте, так как команда определяет каждую историю, и она обязательно разбивает истории, которые пройдут этот горизонт завершения.
Как писать пользовательские истории
При написании пользовательских историй учтите следующее:
- Определение «Готово» - история обычно «завершается», когда пользователь может завершить намеченную задачу, но обязательно определите, что это такое.
- Выделите подзадачи или задачи - решите, какие конкретные шаги необходимо выполнить, и кто отвечает за каждый из них.
- Персона пользователя - для кого? Если есть несколько конечных пользователей, рассмотрите возможность создания нескольких историй.
- Упорядоченные шаги - напишите историю для каждого шага в более крупном процессе.
- Прослушайте отзывы - поговорите со своими пользователями и поймите проблему или потребность в их словах. Не нужно гадать на истории, когда вы можете получить их от ваших клиентов.
- Время - время является деликатным предметом. Многие команды разработчиков вообще избегают обсуждение времени, полагаясь вместо этого на свои системы оценки. Поскольку истории должны быть завершены в одном спринте, истории, которые могут занять недели или месяцы, должны быть разбиты на более мелкие истории или должны рассматриваться как их собственный эпик.
Как только пользовательские истории будут четко определены, убедитесь, что они видны для всей команды.
Шаблон и примеры пользовательских историй
Пользовательские истории часто выражаются в простом предложении, структурированном следующим образом:
«Как [персона], я [хочу], [так что]».
- Разбивая это:«Как [персона]»:Для кого мы это строим? Мы не просто за названием должности, мы за персоной человека. Макс. Наша команда должна иметь общее представление о том, кто такой Макс. Надеюсь, мы взяли интервью у Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. У нас есть сочувствие к Максу.
- «Хочет»: здесь мы описываем их намерения, а не функции, которые они используют. Чего они на самом деле пытаются достичь? Это утверждение должно быть свободным от реализации - если вы описываете какую-либо часть пользовательского интерфейса, а не цель пользователя, вы упускаете суть.
- «Так вот»: как их непосредственное желание сделать что-то, что вписывается в их общую картину? Какую общую выгоду они пытаются достичь? Какую большую проблему нужно решить?
Например, пользовательские истории могут выглядеть так:
- Как Макс, я хочу пригласить своих друзей, чтобы мы могли пользоваться этой услугой вместе.
- Как Саша, я хочу организовать свою работу, чтобы чувствовать себя лучше.
- Как менеджер, я хочу быть в состоянии понять прогресс моих коллег, чтобы я мог лучше сообщать о наших успехах и неудачах.
Эта структура не обязательна, но она полезна для определения сделанного. Когда эта персона может захватить их желаемую ценность, тогда история завершена. Мы призываем команды определить свою собственную структуру, а затем придерживаться ее.
Начало работы с Agile пользовательскими историями
Пользовательские истории описывают причины и то, что стоит за повседневной работой членов команды разработчиков, часто выражая их как личность + потребность + цель. Понимание их роли в качестве источника правды о том, что ваша команда предоставляет, но также и почему, является ключом к плавному процессу.
Начните с оценки следующего или наиболее актуального крупного проекта (например, эпика). Разбейте его на более мелкие пользовательские истории и поработайте с командой разработчиков для уточнения. После того, как ваши истории вышли в открытый свет, где их может увидеть вся команда, вы готовы приступить к работе.
По материалам Agile Coach "User Stories with Examples and Template"