User story пример

Как и зачем писать пользовательские истории – user stories

21-09-2017, 16:10

Tags: agile, user stories

В предыдущем посте об оценке задач и как может имеет смысл от этого отойти, я упомянал “юзер сторис” или пользовательские истории (user stories). Давайте сегодня поговорим об этом подробнее, но без ухода в дебри.

Начнем с базового понятия – пользовательские истории пришли для того чтобы заменить список требований. А почему agile именно так подходит к решению? Чем список требований помешал, ведь в итоге именно его и нужно выполнить, разве не так? Совершенно верно, возразить тут нечего, все именно так и обстоит и проблема совершенно не в списке задач.

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

Давайте разберемся в ситуации.

Задачи программистам приходят со стороны бизнеса, как ответ на некую необходимость:

  • Хотим начать продавать товары “бандлами”, то есть пользователь может найти товар и ему предлагается добрать в корзину товары из смежной категории
  • В стране меняется валюта (проходит деноминация) и нужно поддержать это на сайте. Нужно писать обе цены вместе: “цена до” и “цена после”
  • На сайт заходят много посетителей с мобильных телефонов, явно выделяются пользователи с андроидами, можем ли мы как-то это использовать? (Намек на PWA)
  • и т.д

Это нормальные задачи, которые может ставить бизнес. Явно, что задачи связаны с техническим решением, поэтому конечно они приходят в R&D и все они сформированы как пользовательские истории. В чем преимущество сторон в таком подходе?

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

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

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

Что должны включать в себя пользовательские истории (п.и.)?

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

Простой шаблон п.и. будет следующим: <Кто (тип пользователя)> нужно (некое действие) <Что>, <Почему>. Несколько примеров историй с некоего сайта путешествий:

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

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

Поскольку формулировка истории достаточно короткая, то нам необходимо как-то добавить критерии выполнения, иначе правильное выполнение будет невозможно. Критерия выполнения вполне могут родиться в процесс обсуждения истории. Например, для истории “Пользователю нужно иметь возможность отменить резервацию” критерии могут быть:

  • Только пользователь класса “премиум” может отменять в день заезда без штрафа.
  • Любой другой пользователь при отмене в день заезда платит 10% штраф от суммы заказа.
  • После отмены пользователю должно быть отправлено эл. письмо с подтверждением.
  • Отель так же должен получить уведомление по эл. почте.

После того как критерии поняты мы можем начать писать “саб-таски” для истории. Саб-таски предназначены для определения и распределения задач между программистами. Саб-таски и критерии взаимозаменяемы, однако имеет смысл использовать и те и другие, потому что каждая группа предназначена для “своего пользователя”.

Ссылки по теме:

Поделиться: comments powered by

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

User story или «пользовательские истории/пожелания пользователя» являются методикой, опирающейся на другие практики agile, включая принципы непрерывной поставки и непосредственного общения с пользователями. Недостаточно просто понять, каким будет ваш пользователь; реальный пользователь вашей системы должен находиться рядом с командой на протяжении длительного времени.

User story вкратце описывает:

  • человека, использующего систему (заказчик);
  • то, что должно содержаться в данной системе (примечание);
  • то, для чего она нужна пользователю (цель).

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

Обсудите историю перед планированием этапов с:

  • соответствующими членами команды;
  • экспертами по данному вопросу;
  • заинтересованными сторонами.

Карточки пожеланий пользователя

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

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

Вы можете выработать список критериев приемки при выполнении пользовательских требований к системе. Он должен стать напоминанием к тому, чтобы протестировать или проверить определенные вещи, которые могут быть затронуты при обсуждении. Но не нужно ориентироваться на него при определении объемов работ на основании user story.

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

Структура

Карточка составляется по стандартной схеме:

  • заголовок;
  • заказчик (actor, актер);
  • примечание;
  • цель.

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

Движение «от цели»

Создание полезных программных систем трудоёмко, поэтому вы должны быть уверены, что решаете правильную проблему. В гибких методологиях применяют подход «от обратного» – что пытается получить пользователь системы на выходе? Если вы углубитесь в решение данного вопроса без достаточного понимания ваших пользователей, вы рискуете решить не ту проблему или найти решение, которое на самом деле не подходит вашим пользователям в реальной жизни. Поэтому самой важной частью user story является её цель.

Цель

Понимание целей поможет вам при решении вопроса о том, выполнили ли вы требования пользователя, иными словами, соответствует ли проделанная вами работа цели, стоящей перед пользователем?

При написании user story с вашей командой разработчиков всегда начинайте с обдумывания и обсуждения целей вашего пользователя:

  • почему он хочет использовать эту систему?
  • чего он пытается достичь?
  • что заставило его искать ваш сервис?
  • в каких условиях он использует её: дома/на работе/по телефону/во время ухода за ребенком?
  • как часто он пользуется ей?

Сюзанна и Джеймс Робертсон дают отличный совет по этому поводу в третьем издании книги «Mastering the Requirements Process».

Заказчик (актер)

Подробное описание заказчика (актера) поможет вам разбить процесс построения взаимодействия на логически связанные отрезки.
Иногда заказчик будет пользователем вашей системы, в других случаях – администратором, техником или менеджером вашей организации.
Убедитесь, что вы достаточно хорошо знаете своих пользователей на основании уже проделанной работы или проведенных ранее исследований. Если это не так, найдите время расширить свое понимание пользователей.

Примечания

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

Общение с пользователем напрямую

Agile-команды предпочитают общение лицом к лицу подробной документации.

Разговор лицом к лицу:

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

Карточка – это всего лишь шаблон, гарантия, что разговор состоится в подходящее время.

Воспользуйтесь карточками и несколькими вариантами для завязки разговора, чтобы оценить, сколько времени вам понадобится, чтобы завершить работу над составлением user story и поместить её в бэклог проекта.

Когда начнется непосредственно разработка, пообщайтесь с пользователями или их представителями на предмет уточнения деталей требований. User story – это обобщение всех разговоров, набросков и диаграмм – не просто карточка. Необязательно записывать и хранить все разговоры, но нужно правильно интерпретировать их в автоматизированные тесты или работающий код.

Использование пользовательских историй на этом этапе позволит избежать «информационной перегрузки» – болезненного состояния, при котором пытаешься угадать детали какой-либо цели из далекого будущего.

Критерии приемки для user story

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

Истории «работают» только для agile-команд

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

Откуда берутся пожелания пользователя

Пожелания могут поступать из многих мест, но наиболее распространённые источники включают в себя:

  1. Воркшопы по написанию user story (чаще всего происходят на начальном этапе проекта); команда разработчиков и заинтересованные стороны собираются, чтобы обозначить пожелания пользователей.
  2. Интервью с реальными пользователями – в идеале, вы должны найти несколько пользователей, к которым команда разработчиков будет иметь постоянный доступ.
  3. Представители пользователя в составе вашей команды – это может быть сервис-менеджер или владелец продукта.
  4. Наблюдение – посмотрите, как реальные пользователи работают в вашей системе.

Мы обсудили данный материал с рядом стартапов 4-го набора Акселератора ФРИИ [ближайший День открытых дверей Акселератора состоится в следующий четверг 12-го февраля 2015 г.]:

1.

Используете ли вы user story? К каким источникам вы обращаетесь при составлении user story?

Александр Богомолов, экс-проектный менеджер, ПоискСтроек

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

Леонид Тощев, технический директор, Datamonkey

Cкорее нет, чем да. Мы сначала разработали продукт и уже потом общались с пользователями. Да, мы вносили определённые изменения в контент, основываясь на отзывах, но никогда не ставили себе целью полностью основывать «таски» на user story.

Мария Теркина, со-основатель и CEO, Глоберлэнд

Термин user story мы никогда не использовали, но по факту отвечали на вопросы «Кто наш клиент?», «Как он использует наш сервис?» и «Почему ему нужен наш сервис?». Информацию получали из заявок клиентов, которые поступают к нам на сайт, и из личного общения с теми клиентами, кто заказал и кто не заказал наши услуги (услуги переводчиков).

Александр Грицай, CEO, Forecast NOW!

Мы используем методику выявления потребностей клиентов с помощью обратной связи, опросов, живого общения (у нас непростой B2B-продукт, и число клиентов измеряется десятками), ранжируем их, выделяем на спринт приоритетные по критериям полезности для текущих и будущих пользователей, раз в месяц выпускаем обновление.

Ольга Книга, со-основатель и CEO, Merku.ru

Мы используем их, как и любой инструмент — тогда, когда это необходимо. В первую очередь, при проектировании посадочной страницы и новых функций продукта.

Согласны ли вы с утверждением, что методика user story подходит только для agile-команд?

Александр Богомолов, экс-проектный менеджер, ПоискСтроек

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

Леонид Тощев, технический директор, Datamonkey

Сейчас понятие agile настолько размылось– мне кажется, нет таких компаний, которые не agile. Соответственно, user story могут использоваться всеми.

Мария Теркина, со-основатель и CEO, Глоберлэнд

Думаю, user story вписывается в agile-подход, но может использоваться и в других подходах к разработке.

Мария Подоляк, со-основатель Gagarin Labs

Подход к проектированию функционала продукта или интерфейса при помощи user stories – это же изначально не разработка Agile. Так называемые use cases (юс кейсы, примеры использования) существуют давно в практике разработки технических заданий.

Comments Disabled:

Подход такой же, немного был видоизменен под нужды Agile.

В частных разговорах двух менеджеров продуктов можно услышать: «О, мы начали делать новый продукт для распознавания цвета кошек на фотографиях!» В ответ можно услышать: «Давай юс кейс». Мы разговариваем пользовательскими историями, ведь только так можно понять, какая «боль пользователя» решается, какой инновационный или кардинально иной способ решения проблемы используется, как это происходит на уровне функционала. История помогает «примерить» решение на себя.

User stories используются и при проектировании интерфейсов. С этим подходом я познакомилась в Школе проектирования интерфейсов. Мы рисовали портрет пользователя (еще их иногда персонами называют), писали сценарий истории, дальше мы вырезали из бумаги интерфейс для того, чтобы разыграть сценарий или историю (так происходило тестирование гипотезы).

В ноябре я попробовала применить такой же подход для проектирования контент-стратегии компании или продукта на семинаре в Школе интернет-маркетинга в Нижнем Новгороде. И прекрасно получилось. Так что подход применим ко всему в продукте: функционалу, интерфейсу, маркетингу и т.д. Заставляет думать «головой пользователя», понимать его проблему, а не опускаться в галлюцинации.
Так что Agile ничего нового не сделал, просто адаптировал существующий подход под свои нужды.

Ольга Книга, со-основатель и CEO, Merku.ru

Методика user story подходит не для команд, а для конкретных кейсов и историй – когда можно выделить достаточно стандартного пользователя, который будет представлять типовую группу. Другой полезный способ их использования — возвращение к пониманию того, для кого делается проект: для команды или человека, который начинает делать асфальтоукладчик с вертикальным взлётом и отвлекается от контекста решения проблемы конкретной группы людей.

Помимо User stories мы разбирали и другие материалы Gov.uk (с комментариями российских экспертов):

user stories

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

Хотя сами по себе пользовательские истории не относятся к Agile сфере, они все же акцентируют внимание на коллективной работе, что усложняет использование пользовательских историй в не-Agile проектах. Я видел команды, которые, испытывая определенные проблемы в разработке по Agile, в конечном итоге пришли к применению пользовательских историй, напоминающих высоко детализированные традиционные требования. Чрезмерная спецификация может привести к ряду итераций, которые трансформируются в мини водопады на каждой стадии (осуществление анализа, разработка дизайна, написание кода и проведение тестирования), превращаясь в своеобразное упражнение по записыванию огромного количества деталей. Это противоречит принципу Agile Манифеста, а именно что “самым работоспособным и эффективным методом передачи информации команде разработчиков и внутри нее является личное общение”.

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

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

Название:

Поиск кандидатов по должности, специализации и географической локации.

Описание:

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

Критерии приемки:

Механизм поиска кандидатов имеет возможность ввода должности.

Механизм поиска кандидатов имеет возможность ввода специализации.

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

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

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

Выводы

Имеют ли пользовательские истории преимущества перед другими видами спецификации требований?

Ошибка установки соединения с базой данных

Все зависит от ситуации, но в среде коллективного взаимодействия, мой опыт подсказывает мне положительный ответ на этот вопрос.

Пользовательские истории не сделают ваш проект Agile проектом, а их отсутствие вызовет определенные сложности при его трансформации в Agile проект. Тем не менее, пользовательские истории мотивируют определенное количество принципов из Agile Манифеста:

  • Приветствуется изменение требований, даже на поздней стадии разработки. Agile процессы превращают изменение в конкурентное преимущество клиента.
  • Бизнес и разработчики должны работать вместе ежедневно на протяжении всего проекта.
  • Самым работоспособным и эффективным методом передачи информации команде разработчиков и внутри нее является личное общение.
  • Работающее программное обеспечение является основным средством измерения степени прогресса.

Если у вас есть определенная не-Agile среда разработки, помогут ли вам пользовательские истории? Опять-таки, это зависит от команды. Если команда уже вовлечена в водопадный или сложный итеративный тип процесса и использует подход “заблаговременного планирования больших требований”, то такая команда, скорее всего, сама повлияет на пользовательские истории и превратит их в традиционные требования. Пользовательские истории несколько расплывчаты и поддаются последующему уточнению; заблаговременное планирование и создание дизайна отнюдь не относится к их сильной стороне. Детализированная спецификация часто практикуется в управляемой среде тяжелых процессов перед началом написания программного кода с тем, чтобы требования можно было использовать для планирования бюджета и всего проекта. В связи с этим требования становятся источником записи для системы с достаточно ограниченным пространством для коллективного сотрудничества.

Пользовательские истории (при правильном использовании экспертами, такими как Коен и Коберн) просто имеют слишком свободный формат, чтобы подвергнуться полному документированию. С другой стороны, если команда открыта для коллективного сотрудничества с аналитиками и владельцами бизнеса, а спонсоры проекта согласятся с изменением, пользовательские истории смогут помочь коллективному сотрудничеству.

Автор: Charles Suscheck

Оригинал статьи: http://www.agileconnection.com/print/art[…]traditional-vs-use-cases-vs-user-stories

Пользовательские истории (User Story) помогают разработать функционал, действительно востребованный и удобный для посетителей сайта и пользователей приложений. Как их придумать и применить на практике, разберем в статье.

Понять потребности

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

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

Главный принцип разработки пользовательских историй – ориентироваться на потребности. Чтобы их понять, используются такие приемы:

  • Создание покупательских персон. Кто наши посетители? Зачем они приходят на сайт? Что они хотят получить? Ответы на эти вопросы важны не только для описания целевой аудитории, но и для написания пользовательских историй.

    Зная потребности сегментов ЦА, можно строить гипотезы о необходимом функционале.

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

    Как и зачем писать пользовательские истории – user stories

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

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

В общем и в частности

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

  • назвать пользователя (покупатель детских игрушек, владелец автосалона, предприниматель и т.д.);
  • определить потребность (чего он хочет?);
  • определить цель (зачем ему это надо?).

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

Соответственно, мне нужно увидеть на сайте прайс-лист, оценить репутацию компании, задать уточняющие вопросы.

И наоборот: я как поставщик офисной техники хочу показать на сайте все свои конкурентные преимущества, чтобы выбирали меня. Для этого мне нужно разместить прайс-лист и отзывы клиентов, предоставить возможность быстро связаться с менеджером, рассказать про особые условия при постоянном сотрудничестве.

И в том, и в другом примере мы видим, что общее описание задачи помогает создать список того, что должно быть на сайте. Но во втором случае деталей больше, поскольку поставщику есть, что рассказать.

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

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

Детализация и выставление приоритетности

Приведенные выше примеры показали, что решение одной описанной задачи может потребовать выполнения ряда действий по разработке сайта. Поэтому пользовательские истории необходимо дробить, выделяя отдельные, например, так:

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

Ясно, что подключение сервиса «обратный звонок» и создание страницы с отзывами и рекомендациями – это отдельные задачи. Детализация историй помогает не только выявить их, но и расставить в порядке приоритетности: к примеру, сначала подключаем call-back виджет, потом заказываем отдельную страницу для сканов благодарственных писем.

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

В заключение

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


 
ссылка на эту статью: Что такое User Story?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *