Pull to refresh
0
Фонд развития интернет-инициатив
Экспертиза и инвестиции для стартапов

Работаем с User stories: Руководство Gov.uk

Reading time 8 min
Views 93K
Original author: Gov.uk
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 (юс кейсы, примеры использования) существуют давно в практике разработки технических заданий. Подход такой же, немного был видоизменен под нужды Agile.

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

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

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

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


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

Tags:
Hubs:
+19
Comments 1
Comments Comments 1

Articles

Information

Website
iidf.ru
Registered
Founded
2013
Employees
31–50 employees
Location
Россия