О чем речь? User Story в переводе с английского означает «пользовательская история». Ее задача – как можно более понятно описать особенности конкретного продукта, его функциональные возможности и ценность для конечного потребителя.
На что обратить внимание? Есть определенные правила составления User Story, а также критерии оценки получившегося в итоге материала. И только изучив их досконально, можно рассчитывать, что описание продукта будет сформулировано грамотно.
В статье рассказывается:
- Понятие User Story
- Задачи, решаемые User Story
- Преимущества пользовательских историй
- Простой шаблон user story
- Критерии INVEST для User Story
- 6 полезных советов по написанию пользовательской истории
- 7 распространенных ошибок при составлении User Story
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Суть User Story
User Story – термин, который обозначает общее описание возможностей программы. Текст воспринимается читателем так, как будто его создавал другой пользователь. В нем говорится о ценности каждой функции ресурса. Примечательно, что User Story – это некий обзор, который представлен в формате повествования.
Важно, что любое программное обеспечение нужно разрабатывать максимально гибко, поэтому внимание разработчика должно быть сфокусировано непосредственно на человеке, который будет им пользоваться. Таким образом, пользовательский опыт – это центральная часть всего процесса. Повествование пишется не техническим языком, его задача заключается в предоставлении команде специалистов контекста. Когда последние прочитают user story, они смогут ответить на следующие вопросы:
- Что они делают?
- Зачем?
- В чем заключается ценность разработки?
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Скачивайте и используйте уже сегодня:
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка
Только проверенные нейросети с доступом из России и свободным использованием
ТОП-100 площадок для поиска работы от GeekBrains
Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽
В какой-то мере User Story следует воспринимать как альтернативу спецификации требований и сценария использования. Но, тем не менее, они имеют ряд существенных отличий друг от друга:
- User Story не перечисляет подробно требования к ресурсу. Повествование делается в общих чертах.
- User Story не может быть слишком длинным документом. Важно, чтобы он был простым для восприятия и понятным любому специалисту, имеющему отношение к разработке.
- UserStory – это текст, который показывает, чем ценно приложение. На реализацию главной функциональности должно уйти всего несколько дней или недель.
- UserStory имеет свою структуру, в ней много списков, в которые легко вносить изменения.
- В начале проекта нет необходимости в детализации юзер стори. Это действие нужно в том случае, если хочется ускорить процесс разработки приложения.
- UserStory не нуждается в поддержке, как только ресурс будет реализован, пользовательская история перестанет быть нужной.
Задачи, решаемые User Story
Сразу отметим, что создание User Story имеет огромную важность, так как решает большое количество задач:
- Рассказывает о потребностях целевой аудитории.
- Оказывает содействие в группировке потребностей на задачи для разработчиков проекта.
- Принимает участие в оценке ресурсов, которые пригодятся в работе.
- Делает контекст задачи максимально понятным для всех участников команды.
- Является базой, на основании которой будет проводиться тестирование с настоящими пользователями.
- Дает возможность правильно расставить приоритеты среди поставленных разработчиками задач.
Этот перечень не окончательный. На самом деле список задач гораздо шире. Кроме того, User Story применяется не только для разработки приложений. Историю следует воспринимать как представление себя в контексте некоторой ситуации. С ее помощью появляется возможность четче понять потребности целевой аудитории.
Преимущества пользовательских историй
Отметим, что некоторые разработчики приложений не видят необходимости в создании User Story. Они склонны считать, что для создания нового ресурса достаточно разбить одну большую задачу (эпик) на несколько маленьких и последовательно решать их. Главное достоинство пользовательской истории заключается не в пошаговом руководстве, а в определении взаимосвязи между задачами и ценностью, которая становится актуальной после их выполнения.
На этом преимущества не заканчиваются. Остальные приведем ниже:
- Фокус на пользователе. Разработка приложения – это не просто последовательное выполнение дел, а решение проблем целевой аудитории.
- UserStory дает возможность коллективу работать слаженно. Главная задача заключается в определении преимущественного решения для пользователя, а также лучшего способа решения сформулированной задачи.
- Пример удачной UserStory – это документ, который позволяет находить нестандартные решения. С ее помощью разработчики определяют критический и творческий подход к выбору наилучшего пути достижения конечной цели.
Читайте также!
Use Case: где используется и как писатьПодробнее - UserStory определяет динамику. Каждая выполненная история – это закрытая промежуточная задача. Конечная цель состоит из таких небольших задач, которые приближают к ее достижению и мотивируют двигаться дальше.
- UserStory дает возможность сократить время, потраченное на разработку продукта, а также сэкономить с финансовой точки зрения на создании исчерпывающей документации. История способствует упрощению работы.
Простой шаблон User Story
Есть определенный шаблон, на основании которого пишется User Story. Его использует подавляющее большинство разработчиков. Чаще всего он состоит из одного или двух предложений, для их написания используется следующая формула:
как <роль или тип пользователя>, я хочу/могу <выполнить действие или получить результат>, чтобы <получить ценность>.
Есть смысл детального рассмотрения шаблона:
- Описание пользователя, того, кто находится по другую сторону монитора. Здесь следует нарисовать максимально подробный портрет, профессии и характеристики занимаемой должности, скорее всего, будет недостаточно. Важно понять, как размышляет человек, в чем заключается его работа, какие цели он ставит перед собой при выполнении служебных обязанностей. Будет идеально, если получится взять интервью у пользователя.
- Функциональность будущего приложения. Важно, чтобы описание функционала включало в себя не только саму фичу, но и цель, которую ставит перед собой пользователь разработки.
- Выгода. Осваивая новое приложение, пользователь знает, какие проблемы ему необходимо решить. В результате он должен получить некоторую выгоду. Какую? Это стоит описать в UserStory.
Если говорить простым языком, то пользовательская история – это ответ на 3 вопроса, которые укомплектованы в одно предложение:
- Кто является пользователем приложения?
- Что он будет с ним делать и какой результат получит?
- В чем заключается цель использования?
Чтобы стало понятнее, рассмотрим конкретные примеры:
- Как <пользователь социальной сети>, хочу <видеть в новостях исключительно веселые публикации>, чтобы <не чувствовать апатию>.
- Как <гипотоник>, я хочу <поддерживать артериальное давление на нормальном уровне постоянно>, чтобы <не пользоваться тонометром несколько раз в день>.
- Как <бармен>, я хочу <научить наливать стакан пива максимально быстро>, чтобы <оперативнее обслуживать посетителей>.
- Как <новый работник организации> хочу <понять, что такое Scrum> чтобы <работа в компании была более продуктивной>.
- Как <бренд-менеджер> хочу <чтобы мне приходили уведомления о рекламе продукции моей компании от торговых представителей по стоимости, ниже той, о которой мы договорились >, чтобы <у меня была возможность оперативной защиты своего бренда>.
- Как <директор отдела, работающего удаленно >, я хочу, <чтобы в наш общий чат был добавлен функционал по общему использованию файлов, аннотаций и различных документов>, чтобы <сотрудники имели возможность работать в коллективе в режиме реального времени и иметь доступ к архивным файлам>.
На основании вышеприведенных примеров можно сделать очевидный вывод, что User Story имеет огромную ценность, так как позволяет понять пользователя в любой сфере деятельности.
Критерии INVEST для User Story
INVEST — термин, который используют для их запоминания. По ним можно провести аналитику User Story и сделать вывод, насколько качественно выполнена работа.
- Independent (Независимый)
Истории между собой не должны быть зависимыми, чтобы впоследствии не столкнуться с проблемами во время имплементации. К примеру, одна из задач не может быть решена без решения последующей, но при этом первая из них является обязательной, а вторая лишь желательной. Увы, в реальности добиться независимости не всегда возможно, поэтому специалистам периодически приходится разбивать одну User Story на несколько более мелких задач.
на курсы от GeekBrains до 24 ноября
- Negotiable (Обсуждаемый)
После того, как будет готов черновик пользовательской истории, необходимо обсудить заготовку с заинтересованными лицами. При необходимости вносятся изменения.
Во время переговоров еще не обсуждается, как будет происходить реализация User Story. На этом этапе идет речь о том, каким способом будут удовлетворяться потребности пользователей.
- Valuable (Ценный)
Каждая User Story имеет полезное значение. Польза проявляется не только в отношении конечного потребителя, но и самого продукта. С ее помощью можно четче определить его ценность и понять, для чего нужна реализация.
- Estimable (Оцениваемый)
Пользовательской истории должна быть присуща предельная ясность. Таким образом, разработчики смогут заранее определить, насколько сложная перед ними стоит задача, сколько сил придется вложить. Именно так проводится оценка задачи, невозможность ее выполнения можно объяснить тремя причинами: история слишком длинная, в документе не хватает сведений, у разработчика недостаточно опыта для выполнения задания.
- Small (Компактный)
Многие разработчики считают, что для пользовательской истории есть смысл установить определенные рамки, за пределы которых она не должна выходить. Речь идет о размерах и времени, отведенном на реализацию. К примеру, есть правило, которое гласит о том, что пользовательская история должна быть выполнена за один день. Конечно, из правила бывают исключения, и на выполнение задачи уходит даже несколько месяцев, но этот срок, как правило, устанавливается заранее.
- Testable (Тестируемый)
Любая User Story нуждается в тестировании. Необходимо убедиться, что она действительно имеет что-то такое, что можно реализовать.
7 полезных советов по написанию пользовательской истории
- Пользовательская история должна быть краткой. Если объем больше, чем допустимый, лучше выполнить написание нескольких маленьких UserStory.
- Авторами пользовательской истории должна быть вся команда разработчиков. Так, вы не упустите ценные нюансы и доведете User Story до совершенства.
Читайте также!
Операторы SQL: какие есть и как с ними работатьПодробнее - Не нужно использовать рабочий сленг, если есть возможность. Помните, чем понятнее пользовательская история, тем лучше. Старайтесь писать ее простым языком, это даст возможность понять ее всем, кто задействован в процессе.
- Разработчики должны оценить в истории, насколько сложной будет реализация, и сколько времени будет потрачено на работу.
История должна включать в себя максимально подробное описание потребностей пользователей.
- В написании User Story не должно быть привязки к различным составляющим пользовательского интерфейса.
- User Story – это документ, важной составляющей которого является описание конечного результата, необходимого компании.
7 распространенных ошибок при составлении User Story
- Предположим, что вы написали качественную UserStory, которая полностью отвечает критериям INVEST и успешно прошла тестирование. Вы считаете, что работа по созданию истории выполнена. Но в один момент ваш клиент решил изменить требования. Если вы не внесете изменения, пользы будет мало. Поэтому, даже если результат превзошел все ожидания, корректировки все же нужно сделать.
- Как бы хорошо не была написана история, старайтесь, чтобы она была понятна не только для вас и заказчика. Использование специфических и профессиональных терминов является нежелательным. Также следует избегать аббревиатур и сокращений.
- Полный лист формата А4 – это много для пользовательской истории. Перечитайте ее и подумайте, какие данные лишние?
- Если у продукта несколько типов пользователей, это нужно отразить в истории. Многие разработчики пишут UserStory лишь для одного типа, тем самым не раскрывают полностью ценность продукта.
- Вы перегружаете свой бэклог историями, вследствие чего вам самим тяжело в них разобраться. Есть смысл навести порядок, убрать то, что уже утратило свою актуальность.
- У вас уже реализовано большое количество Story, а вот заказчики не торопятся принимать их. Но ваш успех зависит именно от последних. Поторопите владельцев продукта, если работы будут приняты слишком поздно, у вас не останется времени на редактирование.
- Многие разработчики пренебрегают обсуждениями, а зря. Обратная связь дает возможность прояснить непонятные моменты, вовремя найти и устранить ошибки. Помните, что вы команда, и ваши действия должны быть слажены.
Итак, User Story – это мощный инструмент, который позволяет создать нужный продукт. При использовании методики обязательно поддерживайте связь со своей командой и клиентами, а также своевременно вносите изменения.