Что такое user story
Пользовательские истории – это не требования
Привет, Хабр! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).
Слоны – не жирафы, а пользовательские истории – это не требования. Они имеют и общие черты и общий контекст, однако это не ставит между ними знак равенства. Тем не менее, многие полагают, что пользовательские истории являются своего рода новым прочтением того, что традиционно называется требованиями к программному обеспечению — ведь, должны же быть требования на проекте, правильно? Так вот, я отвечу — нет, и еще раз нет. Во – первых, это не требования, во – вторых, требования — это не то, что нам на самом деле нужно. Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа «требования в бэклоге» сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования — пользовательскими историями, и вот мы уже «agile»…
Еще один признак возможного недопонимания — распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.
Так что же такое пользовательские истории? Рассматривайте их, как инструмент планирования. С помощью пользовательских историй мы определяем приоритеты, оцениваем и принимаем решение в каком спринте будет реализована соответствующая функциональность. Все это — типичные признаки инструмента планирования, поэтому не стоит пытаться превратить их во что-то другое.
Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками — мы начинаем обсуждение. Мы включаем в коммуникацию сотрудников с различными навыками. И так — по каждой новой фиче.
Поскольку пользовательская история, как таковая, не несет в себе много смысла, мы можем просто отбросить ее по факту реализации соответствующей функциональности. При желании можно тщательно вести статистику количества реализованных историй, но этим вполне можно и ограничиться.
И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника «Specification by Example». Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес — правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что – то пойдет нет так вследствие внесения изменений — нарушение какого бизнес — правила явилось причиной данной дисфункции.
Как я писал ранее, описание бага должно быть простым и четким. Баги – это нечто, разрушающее информацию, это то, что плохо независимо от того, есть ли у нас описание требования, покрывающее данный кейс, или его нет.
Контракт
(автор Маттиас Скарин)
Итак, что мы будем использовать вместо спецификации требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile – контракты. 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.
Наконец, написание пользовательских историй имеет смысл при разработке программного обеспечения, которое, вероятно, будет использоваться повторно. Но если вы хотите быстро создать одноразовый прототип или макет для проверки идеи, в написании историй может не оказаться необходимости. Помните: пользовательские истории не о документировании требований; они нацелены дать вам возможность действовать быстро и как можно быстрее разрабатывать программное обеспечение, не создавая никаких особых накладных расходов.
Пользовательские истории в разработке
Пользовательская история (User story) описывает тип пользователей, чего они хотят и почему. Этот инструмент помогает создать упрощенное описание требований, но при этом таковым не является. Требования — это другой инструмент, с более сложной структурой и описанием.
Обычно User story используют при разработке по методологии Agile. Ранее мы писали, как происходит работа при гибком подходе. На этапе дискавери-фазы обычно разбивают разработку продукта на пользовательские истории, а не на характеристики или требования.
Пользовательские истории — это инструмент планирования. С их помощью мы определяем приоритеты, оцениваем и принимаем решение на каком этапе (спринте) будет реализована та или иная функциональность.
Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками — мы начинаем обсуждение. Включаем в коммуникацию сотрудников с различными навыками. И так по каждой новой фиче.
Большинство команд пользуются шаблоном пользовательской истории, обычно это всего лишь одно или два предложения, написанных по следующей формуле:
Как [описание пользователя ], я хочу [ функциональность ], чтобы [ выгода ].
Детально рассмотрим шаблон:
Описание пользователя. Кем является человек по ту сторону экрана? Личность пользовательской истории не обязательно должна ограничиваться должностью человека. Например, руководителем удаленной команды может быть как и менеджер отдела, так генеральный директор, или любое другое лицо в компании. При построении истории мы должны понимать как думает и работает этот человек, знать его намерения. В идеале у пользователей нужно провести интервью.
Функциональность. Здесь описывается не сама фича, а намерения людей, каких целей они хотят достичь.
Выгода. Для чего пользователи совершают все эти действия? Описываем конечную выгоду и проблемы, которые хочет решить выбранная личность.
На практике пользовательские истории могут выглядеть так:
Важно: Различные пользователи, описанные в историях могут быть одним и тем же человеком, которому для разных задач требуются разные функции.
Вместо того, чтобы писать планы с точки зрения продукта (какие функции нужно создать), User stories разворачивают нас к пользователям. Этот инструмент заставляет составлять каждую предложенную идею для новой функциональности с точки зрения реальных людей, которые будут использовать эту функциональность.Таким образом, мы создаем лучший интерфейс для пользователей будущего продукта.
Также применение пользовательских историй сокращает затраты времени и бюджет на создание исчерпывающей документации, делает работу проще и понятнее.
Что такое пользовательская история?
Так вот, пользовательские истории! Несомненно, это один из основных столпов 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 для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?
Как писать User Story
May 10, 2016 · 19 min read
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
User Story — это не требования.
Несмотря на то, что user story играют в огромной степени роль, ранее принадлежавшую спецификациям требований, сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Структура user story
«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“. Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:
Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.
Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.
Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.
Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание».
Actor
C актером все б олее-менее просто. Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла — значит эта часть бесполезна.
Вы определили роли в Системе и поняли что их не очень много — Пользователь, Оператор и Админ. И креативите по 100 историй, которые начинаются как “Как Пользователь Я …”. У вас закрываются несколько спринтов, истории которых начинаются одинаково. Зачем вам это нужно? Да, это бесполезно.
Джеф Паттон предлагает следующее:
Действие
Наверное здесь сложно ошибиться — это суть истории, “что нужно сделать”. Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать “авторизуется и выполняется поиск” или “указывает параметры поиска и выполняет поиск”. Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне “ЧТО?” делает, а не “КАК?” Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное “КАК”-решение.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите “чтобы …” и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли — значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки “чтобы”. Это корень зла. ДА, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Представим что вы создали историю — “Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение”.
У меня Аcceptance Сriteria — это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние — “Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ”. То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Но в чем ценность того, что аналитик стал получать отчет быстрее?
Здесь можно перейти к общей постановке Цели для продукта. Чтобы прийти к такой истории вы:
То есть смысл Impact map — это трассировка от User story к общей Цели продукта. Если такой связи нет и вы не можете ее найти — значит вы делаете что-то бесполезное.
То же самое можно сделать в любой момент времени на любом этапе создания продукта. Вы знаете что нужно сделать и это будет полезно, но вот ценность определить однозначно не можете. Вы видите десятки вариантов то, что нужно написать в “чтобы …”. Постройте путь до цели в Impact map. Найти то влияние что вы должны оказать на актера в результате. Не пишите всякую чушь, в которую сами не верите.
Юсторию можно оценить по критериям «INVEST»:
Наиболее распространенные ошибки при написании историй
История для юзера
Пример: «Как пользователь я хочу управлять рекламными объявлениями, чтобы удалять устаревшие или ошибочные объявления»
На первый взгляд, вы не увидите в этой истории никаких изъянов — все элементы на месте. А теперь расскажите-ка, для кого вы собираетесь сделать эту фичу и что этот юзер знает об управлении объявлениями? Он администратор портала объявлений, которому нужно время от времени чистить базу и премодерировать объявления? Или, может, он рекламодатель, которому нужно просматривать список созданных им объявлений и иметь возможность удалять ненужные объявления прямо из этого списка?
Вы могли заметить, что у этих двух пользователей совсем разные роли, с разными ожиданиями с разными требованиями к системе. Основная ошибка этой истории — игнорирование роли и персоны пользователя.
История для продакт оунера
Пример: «Как продакт оунер, я хочу, чтобы в системе была возможность удалять объявления, чтобы юзеры могли удалять объявления»
И опять, вроде бы все на месте, но что-то не так. Для начала эта история формата «хотели историю? — получили». Очевидно, что автор истории написал ее исключительно ради самого написания:) Конечно, ваш продакт оунер может написать все истории со своей точки зрения, а не с точки зрения нужд конечных пользователей, но это означает всего 2 вещи: вы движетесь не в ту сторону и у вас проблемы с имплементацией аджайла. Возьмите вашего продакт оунера за шкирку, потрясите его хорошенько и заставьте думать головой:)
История для девелопера
Пример: «Как девелопер, я хочу заменить виджет папок, чтобы у меня был лучший виджет папок:)»
Часто такие истории становятся частью technical debt, который состоит из переход на обновленные версии фреймворков и библиотек, рефакторинга и так далее. У них есть полное право на то, чтобы быть сделанными, но на словах они не представляют никакой ценности для юзера и вам достаточно тяжело будет заставить продакт оунера «купить» их. К тому же по хорошему любая история должна создавать пользовательскую ценность и ваша команда должна уметь рассказать на демо, зачем она все-таки заимплементила ее. Так как же поступить с этой историей?
Перепишите ее с пользовательской точки зрения: «Как рекламодатель, я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»
Технические задачи к этой истории могут выглядеть так:
При этом к такой истории гораздо проще написать критерии приемки:
Никакой бизнес ценности для пользователя
Пример: «Как рекламодатель, я хочу чтобы у меня была возможность фильтровать объявления»
У нас есть роль, есть потребность, но причина или бизнес ценность куда-то запропастились. Зачем рекламодателю фильтровать объявления? Чего он хочет достигнуть? Не думайте, что это буквоедство, история действительно теряет смысл без нужных элементов.
Никаких критериев приемки
В любом из примеров приведенных выше, кроме истории для девелопера, нет критериев приемки. Истории могут проваливать тесты, или тест кейсы могут проверять не те критерии из-за отсутствия понимания того, как должен выглядеть конечный результат и каким требованиям он должен соответствовать. Критерии приемки нужны именно для того, чтобы рассеять ложные предположения, а иногда даже перепланировать историю или разбить ее на меньшие.
Практические советы по написанию пользовательских историй
Сомнительные практики
Рекомендации от ведущих специалистов Scrum
Анна Минникова, Гиперболоид, сертифицированный Scrum Professional, работала продакт и проджект менеджером в крупнейших геомобильных приложениях СНГ, сейчас занимается lean коучингом.
1. Как правильно написать User Story?
Командой. Причем команда обязательно должна включать в себя менеджера продукта/клиента/стейкхолдера или даже конечных пользователей вашего продукта. Пишите user story не для того, чтобы получить формальные «требования», а чтобы вытащить на свет все важные для вашего продукта, бизнеса и пользователей нюансы.
Обязательно формулируйте персоны вашего продукта до начала работы над user story. Это поможет вам лучше прочувствовать пользовательские нужды/боли/желания и лучше понять, для кого вы проектируете ваш продукт.
Ваша идеальная история должна быть написана по такому образцу:
Сейчас вы сформулировали бизнес-ценность для пользователя вашего продукта. Но прелесть пользовательской истории в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования. К этой простой формулировке вы можете добавить критерии приемки, технические заметки, описание обработки ошибок, которые суммируют все задачи, которые вам нужно сделать.
Вот как в укороченном виде выглядела пользовательская история в одном из моих проектов:
Как водитель с загоревшейся лампочкой бензина я хочу быстро найти ближайшую хорошую заправку, чтобы заправиться качественным бензином.
1. При выключенной геолокации пользователя необходимо дать ему информацию о том, где ее включить.
1. Заправки в списке должны обновляться при изменении местоположения пользователя на 100 метров.
Такая формулировка задачи помогает разработчикам и тестировщикам не пытаться сравнивать готовую задачу с ui требованиями, которые быстро устаревают, а смотреть на основные проблемы, которые должны быть решены в рамках задачи. Дополненная прототипами, такая история легко становится задачкой в джире или бейскемпе, которую можно делать даже без финального дизайна.
Вот как выглядели экраны, относящиеся к этой истории, в итоговом приложении:
2. Как объективно оценить ее полезность и востребованность?
Пользовательские истории полезны, если вы понимаете, что с написанием пользовательской истории для самого простого проекта вы ступили на тяжелый путь сомнений: «зачем мы делаем наш продукт»?, «точно ли нужна эта фича в продукте?», «да пользователей с такими потребностями днем с огнем не сыщешь», «кто будет пользоваться тем, что мы делаем?». Эти вопросы не очень приятны, но честные ответы на них помогут вам спроектировать лучший продукт.
3. Чего делать не стоит при работе с User Story?
Писать их в гордом одиночестве или поручать написать пользовательские истории, к примеру, менеджеру проекта. Если, конечно, вы не являетесь конечным core пользователем продукта, который вы разрабатываете 🙂
Также не очень здорово писать объемные, большие истории. Если ваша история не вмещается в стандартную итерацию вашей команды (я надеюсь, что это максимум 4 недели:), то она слишком велика и стоит задуматься, как можно ее поделить на несколько.
И самые главные грабли — писать пользовательские истории, которые пойдут в разработку, до того, как вы прошли через процесс customer development. Хорошо сделать это для общего понимания того, что пользователь, по вашему мнению, будет делать с продуктом.
Но пользовательские истории нужно писать не только для того, чтобы выразить ваше мнение о продукте или мнение заказчика. Они должны выражать мнение тех, кто будет покупать и пользоваться продуктом (не забудьте о том, что это не только конечные пользователи, но и те, кто оказывают влияние на совершение покупки. К примеру, конечными пользователями игр часто являются дети, но покупают их родители).
Поэтому для того, чтобы написать ценную и реалистичную пользовательскую историю, вам нужно получить максимум информации о ваших будущих пользователях:
Это самый большой и объемный пункт, поэтому очень хочу порекомендовать к прочтению 2 книги:
Four Steps to the Epiphany — библия customer development, которая даст вам фундаментальное понимание об этапе создания продуктов, которые вам нужно пройти перед тем, как написать пользовательские истории.
User Stories Applied — самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории.
Евгений Плохой, CEO at CapableBits, Founder of CBLabs.mobi
1. Как правильно написать User Story?
Хорошая User Story должна соответствовать модели INVEST.
2. Как объективно оценить ее полезность и востребованность?
Объективно оценить её полезность и востребованность достаточно сложно, т.к. непосредственно в процессе разработки она не участвует, а служит отправной точкой. Это способ начать диалог без понятных маркеров его завершения. Субъективно для нас этот инструмент бесполезен.
3. Чего делать не стоит при работе с User Story?
User story от Юлии Козловой, PR & Event Manager в Touch Instinct
1. Как правильно написать User Story?
Не важно то, как она будет написана и оформлена, главное — насколько правильно и точно она описывает потребности пользователя. В Touch Instinct мы проговариваем пользовательскую историю с клиентом устно, во время переговоров. Делаем заметки. Кто пользователи, чего они хотят? Мы выясняем формализованные потребности: мгновенная покупка, удобное чтение новостей, бронирование мест, заказ билетов и т.д., из которых прорабатываем детальные требования к сценариям использования будущей программы. «Я как пользователь хочу сортировать товары по цене, чтобы выбрать лучшее из одной ценовой категории». «Я как пользователь хочу сохранять музыку в кэш, чтобы слушать без интернета». Далее на основе юз кейсов строим интерфейс, на этом этапе мы понимаем, от какого функционала стоит отказаться, например, нужны ли комментарии к фотографиям или нет.
2. Как объективно оценить ее полезность и востребованность?
Заказчик хорошо знает свой продукт и потребителя. На переговорах мы стараемся вытянуть из него максимальную информацию о том, чего хочет пользователь. Полезность юзер стори прежде всего в том, что они помогают разработчику лучше понять область, продукт, аудиторию заказчика. Мы не совершаем действий ради действий. Востребованность юзер стори оценивается обнаружением и проработкой пользовательских потребностей, на выходе продукт их должен удовлетворять.
3. Чего делать не стоит при работе с user story?
Не стоит зацикливаться и затягивать с проработкой. Зафиксировали ключевой функционал, держите его в фокусе, перед глазами, но не воспринимайте как инструкцию. Юзер стори достаточно гибкая вещь, в которую можно вносить изменения.
Наталия Давыдова, менеджер Heads and Hands
User Story обычно используется при гибких методологиях разработки. В нашей компании часть проектов ведется по такой методологии. Обычно мы организуем встречу с клиентом, на которой просим его описать обычным пользовательским языком пожелания к функционалу сайта или мобильного приложения. На основе этого мы составляем конечное описание работ для итерации (беклог). Правильный пользовательский сценарий, на наш взгляд, должен быть:
Объективно можно оценить полезность в том случае, если по user story можно сформировать удобный и понятный конечному потребителю продукта интерфейс.
При написании user story нужно стараться придерживаться максимально простого описания (без ухода в технические детали), учитывать роли пользователей при работе с продуктом, стараться не увеличивать размер истории, т.к. это должно вписаться в одну итерацию, которая при гибких методологиях длится не более 2х недель.
Пример разработки User Story
1 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
3 Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
Во время обсуждения первой истории, заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» — группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.
4 Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
5 Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.
Пользуясь принципом симметричности требований, команда и заказчик принимают решение, что пользователь должен иметь возможность удалить свою учетную запись в случае необходимости:
6 Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.
Обсуждая концепцию учетных записей, рождаются также следующие истории:
7 Как пользователь я могу изменить данные своей учетной записи.
8 Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.
Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше — интереснее.
ВОПРОСЫ?
К этому моменту, я надеюсь, у вас появилось много интригующих вопросов, даже, может быть, их у вас стало больше, чем до начала чтения этой статьи… Я попробую вкратце разъяснить как же все-таки это все может работать.
КУДА ДЕЛИСЬ ДЕТАЛИ?
Первый вопрос, который задает человек, который привык работать с более тяжеловесным подходом к требованиями (основанным к примеру на подходе Software RequirementsSpecifications из RUP), это «куда подевались детали?»
Это вопрос затрагивает ключевой аспект использования историй. Попробую коротко объяснить.
Конечно, детали есть, и их никто не отменял — как без понимания деталей программист может написать адекватный код, а тестировщик его принять? Детали необходимы. Но использование историй смещает суть и время выработки деталей.
Детали историй — это больше не неизменная часть требований, которые продумываются заказчиками во время написания требований и предъявляются команде в готовом виде. Вместо этого заказчик и команда во время обсуждений историй совместно приходят к понимаю уровня детализации, который необходим на текущей фазе, и принимают совместные решения, пополняя истории все большим количеством информации.
ПРИМЕР ДЕТАЛИЗАЦИИ.
Рассмотрим одну из историй, идентифицированную выше:
4 Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Во время обсуждения этой истории с командой заказчику задают вопрос о том какая информация нужна для создания пользовательской учетной записи. Обсуждая различные варианты, заказчик и команда приходят к тому, что для первой версии системы достаточно будет проверенного электронного адреса плюс имени пользователя и его пароля.
К истории дописывается этой комментарий. Теперь история выглядит так:
4 Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Нужен проверенный email и выбранные пользователем имя и пароль.
В ходе дальнейших высказываний кто-то из тестировщиков задает резонный вопрос о минимальной длине пароля и проверке на уникальности имени. Продолжая дискуссию, команда и заказчики приходят к мнению, что необходимо описать основные критерии готовности истории, чтобы команда понимала ожидания и знала, когда объявлять историю готовой:
4 Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Нужен проверенный email и выбранные пользователем имя и пароль.
Тест 1: пользователь не может ввести пароль меньше 6 символов
Тест 2: пользователь не может ввести имя меньше 3 и больше 20 символов
Тест 3: пользователь должен иметь уникальное имя в системе
Тест 4: после регистрации пользователь должен получить имейл для активизации своей учетной записи
Тест 5: пользователь не может войти в систему, если учетная запись не была активизирована
Тест 6: при успешном входе система приветствует пользователя текстом «Добро пожаловать, »
Возможно во время реализации, тестирования и приема истории возникнут ещё какие-то дополнительные моменты. В этом случае они могут быть описаны в виде уточняющих тестов или как комментарии. Возможно из этих дополнения появятся новые истории.
Таким образом истории пополняются деталями по мере необходимости, эволюционируя от коротких высказываний до детализированных и согласованных требований со встроенными критериями готовности.
МОЩНЫЕ ИНСТРУМЕНТЫ РАБОТЫ С ИСТОРИЯМИ: УПОРЯДОЧИВАНИЕ, РАЗБИЕНИЕ И ГРУППИРОВКА
Как видно, описанные выше истории являются более-менее автономными сущностями, и, как следствие, могут быть перечислены в другом порядке. Конечно между историями существуют связи и логические цепочки — нельзя, к примеру, удалять пользовательские записи, не умея создавать их. Но все таки можно научиться составлять истории таким образом, чтоб обеспечить некоторую свободу в выборе порядка их реализации. Свободы будет, естественно, тем больше, чем больше самих историй и чем независимее они друг от друга.
Если же истории независимы, да к тому же их достаточно много, то можно смело предположить, что их ценность с точки зрения вклада в систему различна. А значит, варьируя порядком историй, можно выставить их в таком порядке, что первые «n» историй будут играть ключевую роль в полезности системы, в то время как другие истории будут скорее необязательными добавками, привлекающими пользователей или облегчающими их работу.
Пользуясь знанием рынка, а также здравым смыслом (к сожалению на сегодняшний день оба этих критерия не поддаются численной оценке), заказчик выстраивает список историй таким образом, чтобы максимизировать возврат вложений от проекта.
Вот пример, как могли бы быть отсортированы истории вышеописанного проекта (это всего лишь один из вариантов, конечно, есть и другие):
4 Как гость я могу зарегистрироваться в системе для получения пользовательской учётной записи и последующей работы.
5 Как гость я могу войти в систему, имперсонализируясь с ранее созданной учётной записью, для последующей работы.
1 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
3 Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
7 Как пользователь я могу изменить данные своей учетной записи для корректировки измененных или неверных данных.
2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
8 Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.
6 Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.
Как вы видете, истории выстроены в порядке, который, во-первых, логичен с точки зрения заказчика и команды, а во-вторых ценность историй уменьшается сверху вниз. Таким образом, если, к примеру, на половине проекта наступает нехватка ресурсов (скажем, после реализации истории для администратора системы), заказчики смогут получить выгоду от продукта, так как наиболее важные истории уже будут реализованы. Это ни что иное как минимизация рисков от вложений.
Конечно, порой не так легко и очевидно принять правильное решение о порядке историй, но в этом и состоит мастерство быть заказчиком (это отдельная, неисчерпаемая тема…)
Кроме инструментария ранжирования историй, в руках у заказчика есть и другие мощные средства, позволяющие повысить эффективность своих финансовых вложений. К примеру, одна из описанных на ранней фазе проекта историй в какой-то момент может показаться слишком большой в сравнении с другими, что усложняет понимание её приоритета:
1 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
В этом случае заказчик и команда могут попробовать разбить ее на несколько более мелких историй, каждая из которых может получить свой приоритет:
9 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать их другим пользователям.
10 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность продать их другим пользователям.
При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими.
Подобный процесс разбиения сложных и больших истории на более простые может осуществляться в теории довольно долго. На практике же, заказчики и команда в скором времени вырабатывают совместное понимание адекватного размера историй и следуют ему при написании новых и разбиении существующих историй. Этот размер зависит от количества историй, реализуемых за итерацию. Но об этом поговорим подробнее, обсуждая планирование.
Механизмом, обратным разбиению, служит группировка историй. Иногда бывает полезно склеить мелкие истории в одну побольше для улучшения понимания связности историй.
Я уверен, вы неоднократно будете пользоваться этими простыми но мощными средствами управления требованиями, когда начнете использовать истории в своих проектах.
Как вы до сих пор справлялись с подобными задачами?
ДИНАМИКА ЗНАНИЙ
Программный продукт — это не только код и документация. Это также знания о пользователях, рынке, особенностях продукта, технологиях и прочее. Если же проект — это развитие продукта, то тогда в нем должны гармонично изменяться все его составные части: код, документация и знания. А, следовательно, знания динамичны. Таким образом, что вчера казалось фактом, сегодня в свете новоприобретенных знаний таковым может уже не быть. Для историй это значит, что порядок приоритезации историй, сделанный вчера, уже сегодня, возможно, должен быть изменен.
И в этом нет ничего плохого: меняется мир, также меняются наши знания о мире. И это такой же факт для индустрии программного обеспечения, как и для всего остального.
Вот ещё один плюс хранения требований в виде списка относительно независимых историй. Его в любой момент можно пересортировать, добавить новые или удалить ненужные истории. Хранение требований в виде историй не препятствует динамичности знаний, а наоборот, базируется на том, что наши знания будут и должны меняться, иначе продукт устареет, ещё не начав использоваться.
ЧТО ДАЛЬШЕ?
Когда начальный набор историй готов, все истории обговорены и детализированы до нужной степени, ничего больше не остается, как перейти к их реализации, выпуская программный продукт, в соответствии с приоритетами заказчиков и желаниями пользователей.
Про оценивание размера историй, планирование историй по итерациям, предсказание времени готовности историй и прочие важные аспекты речь пойдет во второй части статьи.