пользовательская история в agile
Что такое пользовательская история?
Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.
Одним из принципов agile-разработки является идея разбиения крупных разработок на более мелкие части, называемые историями. На пути к тому, чтобы стать ниндзя-мастером на позиции продакт-менеджера и приносить пользу клиентам с помощью своего продукта, вам придется заботиться о бэклоге и содержащихся в нем пользовательских историй.
Но что такое пользовательская история?
Чтобы ответить на этот вопрос, давайте разделим это понятие на части:
История, в данном контексте, — это «устное или письменное изложение материала в художественной форме».
Пользователь — это человек, который владеет или пользуется чем-то по желанию, то есть человек, который использует компьютер, программное обеспечение, системы или компьютерные услуги.
Таким образом, можно сказать, что история пользователя — это письменное повествование об использовании системы.
Когда мы говорим о методологии agile-разработки, пользовательская история — это инструмент, который помогает переключить внимание с детализации требований к системе на их обсуждение.
Обычно это делается с помощью предложений, в которых говорится об удовлетворении требования, например:
Шаблон пользовательской истории
Давайте приведем несколько примеров обычных историй для иллюстрации?
Как менеджер по маркетингу, я хочу знать источник и механизм получения информации о том, что послужило причиной покупки на нашем сайте, чтобы понять, какие каналы коммуникации лучше всего подходят для реализации нашего продукта.
Как руководитель компании, я хочу знать среднюю величину дохода по каждому проданному продукту, чтобы решить, куда вкладывать больше или меньше средств.
Одно из преимуществ следования этой модели заключается в том, что автор истории вынужден сосредоточиться на «ЧТО», а не на «КАК» — за последнее отвечает команда разработчиков.
При создании новой истории автор всегда должен сосредоточиться на описании своих потребностей и цели, которую он пытается достичь с ее помощью. Благодаря этому команда, выслушав историю и не будучи ограниченной уже предложенными попытками решения, может свободно создать или предложить наилучшую альтернативу для решения проблемы.
Кто является действующими лицами или персонами в историях?
Это конечные пользователи историй. Именно они часто их пишут или запрашивают.
В примерах выше в качестве действующих лиц мы используем менеджера по маркетингу и руководителя компании, но участниками могут быть все, кто имеет отношение к вашему продукту, конечный клиент, внутренний пользователь, внешний пользователь, сам PM (продакт-менеджер) и т.д.
Только ли PM должен писать истории?
Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.
Задача PM, однако, состоит в том, чтобы убедиться, что истории хорошо описаны и содержат достаточно информации, чтобы команда могла их легко понять. Именно на основе конкретной пользовательской истории команда будет планировать свою работу и оценивать ее сложность.
Плохие пользовательские истории
Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?
A) «Не хватает кнопки загрузки».
B) «Я бы хотел, чтобы на прикрепленном экране отображалось больше информации о продукте».
C) «Включите больше изображений».
Один из способов превратить плохие истории в нечто полезное — использовать метод 5 Whys ( 5 “Почему«). Он также помогает автору быть более подготовленным и правильно описать свою следующую историю.
Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.
Проблема: «Не хватает кнопки загрузки».
Обладая этой информацией, можно было бы улучшить исходную историю, например:
Я хочу экспортировать данные из отчета XYZ в формате CSV;
Чтобы вы могли предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки
Не стоит забывать, что хорошая пользовательская история также содержит четко сформулированные критерии приемки.
Критерии приемки, как следует из названия, — это критерии, по которым история может быть принята или отклонена.
Они представляют собой набор инструкций, каждая из которых дает четкий результат «прошел или не прошел» — например, контрольный список, в котором указаны функциональные и нефункциональные требования.
Критерии приёмки в конечном результате представляют собой «Определение выполненного» и, по существу, хорошо выполненного.
Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:
Как BI-аналитик, я хочу экспортировать данные из отчета XYZ в формате CSV, чтобы предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки:
— При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;
— При нажатии на кнопку загрузка начинается автоматически;
— Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;
Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет «Agile» (гибко), если это история с 423 критериями приемки.
Всех желающих приглашаем на открытый урок «Бизнес- и системный анализ как подготовка к тестированию качества программного продукта». На этом демоуроке обсудим:
— Зачем нужны User story для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?
Пользовательские истории с примерами и шаблоном
Пользовательские истории — это задания на разработку, которые часто выражены в форме «тип пользователя + потребность + цель».
Просмотр тем
Краткое описание: пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя. Она пишется с целью разъяснить, как именно функциональная возможность принесет пользу клиенту.
Есть тенденция считать, что пользовательские истории — это, говоря проще, функциональные требования к программному обеспечению. Но это не так.
Уникальная черта agile-разработки ПО — ставить во главу угла человека, и пользовательские истории как раз служат для того, чтобы в центре обсуждения всегда были фактические пользователи. Истории пишутся простым языком, без технической специфики, и служат контекстом для команды разработчиков и их деятельности. Прочитав пользовательскую историю, команда знает, почему она создает то, что создает, и какую ценность это формирует.
Пользовательские истории — одна из базовых составляющих agile-программы. Они позволяют организовать повседневную работу в систему, ориентированную на пользователей, что способствует укреплению сотрудничества, поиску нестандартных идей и повышению качества продукта в целом.
Что такое пользовательские истории в agile?
Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО.
Пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя или клиента.
Пользовательская история пишется с целью разъяснить, как именно выполнение рабочей задачи приведет к созданию конкретной ценности для клиента. «Клиентами» необязательно должны быть сторонние конечные пользователи в привычном смысле слова. Эту роль могут на себя примерять внутренние клиенты или коллеги из организации, которые рассчитывают на вашу команду.
Пользовательские истории состоят из нескольких предложений, описывающих требуемый результат простым языком и в общих чертах. Они не содержат мелочей. Требования появятся позже, когда команда обсудит их и придет к согласию.
Пользовательские истории изящно вписываются в методики agile, такие как Scrum и Kanban. В Scrum пользовательские истории добавляют в спринты и отслеживают на диаграммах Burndown в течение спринта. Команды, работающие по методике Kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так Scrum-команды совершенствуют свои навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут далее совершенствовать свои рабочие процессы.
Пользовательские истории также составляют более крупные элементы методик agile, такие как эпики и инициативы. Эпики — это крупные рабочие задачи, которые делятся на несколько историй. Группа эпиков образует инициативы. Благодаря этим крупным структурам команда разработчиков выполняют свою повседневную работу (над историями) так, что это ведет к достижению целей организации, выраженных в эпиках и инициативах.
Зачем нужны пользовательские истории?
Для команд разработчиков, которым agile в новинку, пользовательские истории кажутся лишним шагом. Почему бы просто не разбить большой проект (эпик) на несколько шагов, а потом разбираться с ними? Но с историями команда получает необходимый контекст и связь между задачами и ценностью, которая возникает в результате выполнения этих задач.
Пользовательские истории обладают несколькими важными преимуществами.
Работа с пользовательскими историями
Когда история написана, самое время встроить ее в рабочий процесс. Как правило, историю пишет владелец продукта, менеджер по продукту или руководитель группы проектов, после чего она отправляется на проверку.
В ходе собрания по планированию спринта или итерации команда решает, какие истории она выполнит в ходе этого спринта. На этом этапе команды обсуждают требования каждой пользовательской истории и связанные функциональные возможности. Это шанс проявить свои навыки и творческий потенциал и внести вклад в воплощение истории в жизнь вашей командой. По завершении согласования требования добавляются в историю.
Еще на собраниях оценивают истории на основании их сложности или времени, которое нужно потратить на выполнение. Команды высчитывают оценки в размерах футболок, баллах из последовательности Фибоначчи или с помощью покера планирования. Размер истории должен позволять выполнить ее за один спринт, поэтому в ходе оценки каждой истории команда следит, чтобы слишком трудоемкие или затратные по времени истории разбивались на меньшие части.
Как написать пользовательскую историю
При написании пользовательских историй держите в уме следующее.
Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.
Шаблон и примеры пользовательских историй
Пользовательские истории часто представлены в виде простого предложения следующего вида:
«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».
Давайте разберем эту формулировку.
Пользовательские истории могут выглядеть, например, следующим образом.
Придерживаться такой структуры необязательно, но она помогает определить критерии готовности работы. История выполнена, когда упомянутый тип клиента получает требуемую ценность. В идеале, команды формулируют свою собственную структуру и придерживаются ее.
Начало работы с пользовательскими историями в agile
В пользовательских историях раскрываются суть и цели повседневной работы участников команды разработчиков. Зачастую они написаны в форме «тип клиента + потребность + цель». Чтобы процесс работал как часы, важно понимать роль историй: именно в них объясняется, что должна сделать команда и почему она должна это сделать.
Начните с оценки следующего или самого срочного крупного проекта (например, эпика). Разбейте его на небольшие пользовательские истории и вместе с командой разработчиков доведите до ума. Когда истории будут готовы и представлены на суд всей команды, можно приступать к работе.
Насколько детальной должна быть User Story?
В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.
Некоторым разработчикам хотелось бы видеть максимально подробное описание, прочитав которое, они могли бы сразу всё понять и быстро сделать, ни к кому не обращаясь с вопросами. Руководству также зачастую импонирует такой подход, ведь программисты стоят дорого, нужно сделать так, чтобы они не отвлекались ни на что постороннее.
Рассмотрим Agile-подход к решению этой проблемы.
Для начала разберемся с концепцией CCC, которая расшифровывается как Card, Conversation, Confirmation.
Card (Карточка)
Идея состоит в том, что вся User Story должна поместиться на небольшую бумажную карточку или стикер. Много на ней не напишешь, да это и не нужно.
Главное предназначение карточки – служить напоминанием, приглашением к обсуждению (placeholder for conversation).
Цель – сместить фокус с написания требований на их обсуждение. Ибо живое обсуждение более важно, чем написанный текст.
Карточка должна коротко, но емко отражать суть задачи. Предлагаемый формат:
Про функциональность в описании User Story забывают редко, а вот о том, кому она нужна и зачем, порой умалчивают. Явное указание бизнес-контекста весьма полезно для предстоящего обсуждения.
При написании User Story рекомендуется сосредоточиться на пользователе нашего приложения (focus on user needs and benefits).
Функциональность лучше описывать не абстрактно, а с использованием живых примеров (by example).
Первоначальная формулировка User Story делается умышленно нечеткой. Добавление подробностей откладывается до последнего момента, когда продолжать без них уже нельзя.
User Story может ссылаться на развернутые требования, например, протокол взаимодействия или формулу расчета.
Карточка User Story служит также для отслеживания статуса задачи, например, на канбан-доске.
Conversation (Обсуждение)
Обсуждение – наиболее важная часть.
Между разработчиками и Product Owner действует соглашение: разработчики обязуются задавать вопросы, а PO обещает, что будет для них доступен.
Общение, в идеале, происходит лицом к лицу (face to face), так как это наиболее эффективный (high bandwidth) способ передачи информации. Важные аспекты живого общения – это его интерактивность (возможность уточнить и удостовериться), а также обратная связь (один из фундаментальных принципов Agile).
Живое обсуждение позволяет преодолеть или свести к минимуму недостатки, присущие документации:
Confirmation (Подтверждение)
Третий важный аспект User Story – это подтверждение того, что задача выполнена.
Условия приемки (acceptance criteria), а также Definition of Done, оговоренные заранее, позволят вовремя прекратить работу, оценить, достигнута ли преследуемая бизнес-цель.
Для подтверждения задачи agile-команда проводит демонстрацию новой функциональности заказчику, собирает замечания, получая оперативную обратную связь.
Насколько же детальной должна быть User Story?
Вернемся к исходному вопросу и рассмотрим две крайности:
Очевидно, что мы не хотим впадать ни в одну из этих крайностей. Значит оптимум где-то посередине. Чтобы нащупать его, будем использовать концепции “точно вовремя” (just in time) и “ровно столько, сколько нужно” (just enough).
User Story должна содержать ровно столько подробностей, так что недостача хотя бы одной привела бы к тому, что мы не успели бы выполнить задачу в спринте. Добавление подробностей должно происходить точно вовремя, не позже, и не раньше. Смещение в любую сторону снижает нашу эффективность.
Можно ли достичь такого баланса для каждой User Story? Разумеется нет, но надо постоянно подстраиваться.
Поделитесь, пожалуйста, в комментариях, как вы работаете с User Stories. Актуальна ли для вас описанная проблема? Какие другие проблемы, связанные с User Stories, возникают в вашей команде?
Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.
Идеи данной статьи почерпнуты из следующих источников:
10 советов для написания хороших пользовательских историй
Также приглашаем всех желающих участвовать в открытом вебинаре на тему «Как спроектировать REST API и не умереть?». Участники вместе с экспертом на занятии рассмотрят следующие моменты:
• Основные плюсы и фичи REST API;
• Правильное разделение ресурсов в REST API;
• Наследование ресурсов и абстрактные ресурсы.
Пользовательские истории (User stories, юзер стори), вероятно, являются самой популярной техникой аджайл (гибкой методологии) для описания функциональности продукта: с пользовательскими историями очень легко работать. Но «рассказывать» эффективные истории бывает достаточно сложно. Следующие десять советов помогут вам в создании хороших пользовательских историй.
Скачать аудиоверсию можно здесь.
1. Пользователи прежде всего
Как следует из названия, пользовательская история описывает, как покупатель или пользователь использует продукт; она повествует с точки зрения пользователя. Более того, пользовательские истории особенно полезны для отражения конкретных функций, таких как поиск продукта или бронирование. На следующем рисунке показана взаимосвязь между пользователем, историей и функциональностью продукта (обозначена кружком).
Если вы не знаете своих пользователей или клиентов, и почему они хотели бы использовать ваш продукт, вам не следует браться писать какие-либо пользовательские истории. Сначала проведите необходимые исследования пользователей, например, с помощью наблюдения за ними или опроса. В противном случае вы рискуете написать спекулятивные истории, основанные на домыслах и идеях, но не на эмпирических данных и реальных свидетельствах.
2. Используйте персонажей, чтобы найти правильные истории
Отличный способ получить представление о пользователях и клиентах — это работа с персонажами (или персонами — persona). Это вымышленные персонажи, основанные на первичных сведениях о потенциальных клиентах. Обычно они состоят из имени и изображения; соответствующих характеристик, поведения и отношений; и цели. Цель — это выгода, которую хочет достичь персонаж, или проблема, которую персонаж хочет видеть решенной с помощью вашего продукта.
Но это еще не все: цели персонажей помогают вам выявлять правильные истории: спросите себя, какую функциональность должен обеспечивать продукт для достижения целей персонажей (я объясняю это в своей статье «От персонажей к пользовательским историям». Вы можете скачать удобный шаблон для описания своих персонажей с romanpichler.com/tools/persona-template.
3. Совместное создание историй
Пользовательские истории задуманы как легкий метод, который позволяет вам быстро продвигаться. Это не спецификация, а инструмент для совместной работы. Истории никогда не следует спихивать на команду разработчиков. Вместо этого они должны существовать в диалоге: Product Owner и команда должны обсуждать истории вместе. Это позволяет собирать только необходимый минимум информации, сокращать накладные расходы и ускорять доставку продукта.
Вы можете развить этот подход еще дальше и совместно писать истории во время вашего процесса обработки бэклога продукта. Это усиливает творческий потенциал и знания команды и результирует в создании лучших пользовательских историй.
Если вы не можете задействовать команду разработки к работе с пользовательскими историями, вам следует подумать об использовании другого, более формального метода для фиксирования функциональности продукта, например вариантов использования (юзкейсов).
4. Делайте истории простыми и лаконичными
Пишите истории так, чтобы их было легко понять. Старайтесь делать их простыми и лаконичными. Избегайте путаницы и двусмысленных терминов, используйте активную речь. Сосредоточьтесь только на том, что важно, и не отбросьте все остальное. Приведенный ниже шаблон помещает пользователя или покупателя, смоделированного как персонажа, в историю и ясно показывает ее преимущества. Он основан на широко известном шаблоне Рейчел Дэвис, но я заменил роль пользователя (user role) на имя персонажа, чтобы соединить историю с соответствующим персонажем.
Используйте этот шаблон, когда думаете, что он будет полезен, но не чувствуйте себя обязанным применять его всегда и везде. Поэкспериментируйте с разными способами написания своих историй, чтобы понять, что лучше всего подходит вам и вашей команде.
5. Начните с эпиков
Эпик (Epic) — это большая, схематичная, крупномасштабная история. Обычно с течением времени он разбивается на несколько пользовательских историй, на основе отзывов пользователей о ранних прототипах и новых продуктах. Вы можете думать о нем как о преамбуле и временном решении до более подробных историй.
Начало работы с эпика позволяет вам набросать функциональность продукта, не вдаваясь в детали. Это особенно полезно для описания новых продуктов и фич: позволяет охватить приблизительный объем и дает вам время, чтобы узнать больше о том, как наилучшим образом удовлетворить потребности пользователей.
Это также сокращает время и усилия, необходимые для интеграции новых идей. Если у вас много подробных историй в бэклоге продукта, то связать фидбэк с соответствующими элементами часто достаточно сложно, отнимает много времени, и несет в себе риск внесения несоответствий.
6. Уточняйте истории, пока они не будут готовы
Разбивайте свои эпики на более мелкие и подробные истории, пока они не достигнут готового состояния: ясные, выполнимые и проверяемые. Все члены команды разработки должны иметь общее понимание смысла истории; история не должна быть слишком большой, она должна комфортно вписываться в спринт; и должен быть эффективный способ определить, готова ли история.
7. Добавьте критерии приемлемости
Разбивая эпик на более мелкие истории, не забудьте добавить критерии приемлемости (Acceptance Criteria). Критерии приемлемости дополняют истории: они позволяют описать условия, которые должны быть выполнены, чтобы история считалась готовой. Критерии обогащают историю, они делают ее проверяемой и гарантируют, что история может быть продемонстрирована или выпущена для пользователей и других заинтересованных сторон. Как правило, для детализированных историй я люблю использовать от трех до пяти критериев приемлемости.
8. Используйте бумажные карточки
Пользовательские истории пришли к нам из экстремального программирования, и ранняя литература по экстремальному программированию оперирует карточками историй (story cards) а не пользовательскими историями. Причина проста: пользовательские истории были записаны на бумажных карточках. Такой подход дает три преимущества. Во-первых, бумажные карточки дешевы и просты в использовании. Во-вторых, они облегчают сотрудничество: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить последовательность и полноту, а также визуализировать зависимости. Даже если ваши истории хранятся в электронном виде, при написании новых историй стоит использовать бумажные карточки.
9. Делайте ваши истории видимыми и доступными
Истории нацелены передавать информацию. Поэтому не прячьте их на жестком диске, в джунглях корпоративной интрасети или в лицензированном инструменте. Сделайте их видимыми для всех, например, повесив на стену. Это способствует сотрудничеству, создает прозрачность и делает очевидным, что вы добавляете слишком много историй слишком быстро, так как у вас начинает заканчиваться свободное пространство на стене. Мой Product Canvas, показанный ниже, представляет собой удобный инструмент для поиска, визуализации и управления вашими историями.
10. Не полагайтесь исключительно на пользовательские истории
Для создания хорошего пользовательского опыта (user experience, UX) требуется нечто большее, чем пользовательские истории. Пользовательские истории полезны для отражения функциональности продукта, но они не подходят для описания пользовательского пути и визуального дизайна. Поэтому дополняйте пользовательские истории другими методами, такими как карты историй (story maps), диаграммы рабочих процессов, сториборды (storyboards), скетчи и макеты.
Кроме того, пользовательские истории плохо отражают технические требования. Если вам нужно передать, что должен делать такой архитектурный элемент, как компонент или сервис, тогда пишите технические истории или — что предпочитаю я — используйте какой-нибудь язык моделирования, такой как UML.
Наконец, написание пользовательских историй имеет смысл при разработке программного обеспечения, которое, вероятно, будет использоваться повторно. Но если вы хотите быстро создать одноразовый прототип или макет для проверки идеи, в написании историй может не оказаться необходимости. Помните: пользовательские истории не о документировании требований; они нацелены дать вам возможность действовать быстро и как можно быстрее разрабатывать программное обеспечение, не создавая никаких особых накладных расходов.