Пользовательские истории являются неотъемлемой частью гибких методов разработки.
Это позволяет вам разбить вашу работу на ряд задач, каждая из которых добавляет ощутимую ценность проекту.
Все эти задачи можно обсуждать и расставлять приоритеты независимо друг от друга.
Пользовательские истории или «пользовательские истории/пожелания пользователей» — это метод, основанный на других гибких практиках, включая принципы непрерывной доставки и прямого общения с пользователями.
Недостаточно просто понять, каким будет ваш пользователь; настоящий пользователь вашей системы должен быть в команде долгое время.
Пользовательская история кратко описывает:
лицо, использующее систему (заказчик); что должно содержаться в данной системе (примечание); для чего это нужно пользователю (цель).Пользовательская история может быть добавлена в бэклог проекта на любом этапе спринта любым членом команды.
Владелец проекта решает, как координировать и расставлять приоритеты запросов пользователей, и выбирает их в начале каждого цикла спринта.
Прежде чем планировать этапы, обсудите историю с:
соответствующие члены команды; эксперты по данному вопросу; заинтересованные стороны.
Карты желаний пользователей
Пожелание пользователя — карточка с заголовком и несколькими строками текста.Ваши карты могут быть виртуальными или физическими.
При разработке большого продукта/системы сохраните его в цифровом виде, а затем выдайте физические карты в рамках планирования спринта.
Создавая карту с пожеланием пользователя, убедитесь, что оно (пожелание) правильно сформулировано.
Не пропускайте часть, объясняющую необходимость создания этого элемента системы только потому, что это может вызвать у вас затруднения.
Вы можете разработать список критериев приемки для удовлетворения системных требований пользователя.
Это должно служить напоминанием о необходимости протестировать или проверить определенные вещи, которые могут возникнуть в ходе обсуждения.
Но не нужно на него полагаться при определении объёма работ на основе пользовательской истории.
Если запрос слишком объемный, разбейте его на более мелкие части, поскольку такой подход увеличивает вероятность того, что результатом будет код, готовый для последующего использования.
Состав
Карта оформляется по стандартной схеме: заголовок; заказчик (актёр, актёр); примечание; цель.Он не охватывает все детали, но вам следует подробно обсудить пользовательскую историю в подходящее для команды время.
Уходя от цели
Создание полезных программных систем — тяжелая работа, поэтому вам нужно убедиться, что вы решаете правильную проблему.Гибкие методологии используют обратный подход: что пользователь системы пытается получить на выходе? Если вы углубитесь в эту проблему без достаточного понимания своих пользователей, вы рискуете решить неправильную проблему или найти решение, которое на самом деле не поможет вашим пользователям в реальной жизни.
Поэтому наиболее важной частью пользовательской истории является ее цель.
Цель
Понимание ваших целей поможет вам решить, выполнили ли вы требования пользователя, иными словами, соответствует ли проделанная вами работа цели пользователя? При написании пользовательской истории вместе с командой разработчиков всегда начинайте с обдумывания и обсуждения целей вашего пользователя: почему он хочет использовать эту систему? чего он пытается достичь? что заставило его обратиться к вам за услугами? В каких условиях он им пользуется: дома/на работе/по телефону/при уходе за ребенком? как часто он им пользуется? Сюзанна и Джеймс Робертсон дают отличные советы по этому поводу в третьем издании книги «Освоение процесса требований».
Заказчик (актер)
Подробное описание заказчика (актера) поможет вам разбить процесс построения взаимодействия на логически связанные сегменты.Иногда клиентом будет пользователь вашей системы, иногда — администратор, технический специалист или менеджер вашей организации.
Убедитесь, что вы достаточно хорошо знаете своих пользователей, основываясь на уже проделанной вами работе или исследованиях, которые вы проводили ранее.
Если это не так, найдите время, чтобы расширить свое понимание пользователей.
Примечания
Используйте их как блок для передачи информации об основном типе взаимодействия, которое следует рассматривать как часть пользовательского опыта.Помните, что карта не обязательно должна отражать каждую деталь этого взаимодействия.
Общайтесь с пользователем напрямую
Agile-команды предпочитают личное общение подробной документации.Разговор с глазу на глаз:
Быстрее; более точная, чем письменная документация; позволяет разработчикам построить подробную модель целей пользователя, рабочих процессов, ограничений и многих проблем, которые необходимо учитывать при разработке программного обеспечения.Карта — это всего лишь шаблон, гарантия того, что разговор состоится в нужное время.
Используйте карточки и несколько вариантов начала разговора, чтобы оценить, сколько времени вам понадобится, чтобы завершить свою пользовательскую историю, и поместить ее в список невыполненных проектов.
Когда начнется разработка, поговорите с пользователями или их представителями, чтобы уточнить детали требований.
Пользовательская история — это краткое изложение всех разговоров, эскизов и диаграмм, а не просто карточка.
Не обязательно записывать и хранить все разговоры, но вам необходимо правильно интерпретировать их в автоматизированные тесты или рабочий код. Использование пользовательских историй на этом этапе поможет вам избежать «информационной перегрузки» — болезненного состояния, при котором вы пытаетесь угадать детали какой-то цели из далекого будущего.
Критерии приемки пользовательских историй
Критерии приемки помогают, в частности, понять, были ли выполнены пожелания пользователя.Они сопровождают общение разработчика с пользователем или его представителем и оцениваются до начала разработки.
Записывайте их на обратной стороне карточки только в том случае, если команда считает, что они содержат соображения пользователя, которые могут быть забыты позже.
Иногда запись критериев приемки на карточке полезна, если пользователь или представитель пользователя недоступен и некем заменить их при личной встрече.
Истории «работают» только для agile-команд
Успех пользовательской истории зависит от регулярного общения напрямую между разработчиками и пользователями или их представителями.Ваш менеджер по обслуживанию и другие представители пользователей должны быть доступны для общения с разработчиками каждый день и иметь достаточно времени, чтобы обдумать ваши вопросы и ответить на них.
Не стоит недооценивать, насколько трудоемкой может оказаться эта работа!
Откуда берутся пожелания пользователей?
Пожелания могут исходить из разных мест, но наиболее распространенными источниками являются: Мастер-классы по написанию пользовательских историй (чаще всего происходят на начальном этапе проекта); команда разработчиков и заинтересованные стороны собираются, чтобы изложить желания пользователей.Интервью с реальными пользователями.
В идеале вам следует найти несколько пользователей, к которым команда разработчиков будет иметь постоянный доступ.
Представители пользователей в вашей команде — это может быть менеджер по обслуживанию или владелец продукта.
Наблюдение.
Посмотрите, как реальные пользователи работают в вашей системе.
Этот материал мы обсуждали с рядом стартапов 4-го набора Акселератора ФРИИ [ ближайший День открытых дверей Акселератор состоится в следующий четверг, 12 февраля 2015 года.
]: 1. Используете ли вы пользовательские истории? К каким источникам вы обращаетесь при создании пользовательской истории? Александр Богомолов, экс-менеджер проекта «ПоискСтройек» Мы написали [пользовательскую историю] до того, как проектировали новую версию сайта и, как мне кажется, допустили одну большую ошибку.
Прежде чем создавать истории, я не поговорил с достаточным количеством потенциальных пользователей.
В результате мы получили истории, основанные на наших предположениях, которые отличались от реальных потребностей и могли увести проект в неправильном направлении.
Леонид Тощев, технический директор Datamonkey Скорее нет, чем да.
Мы сначала разработали продукт и только потом общались с пользователями.
Да, мы внесли определенные изменения в контент на основе отзывов, но мы никогда не ставили перед собой задачу полностью основывать наши задачи на историях пользователей.
Мария Теркина, сооснователь и генеральный директор Globeland Мы никогда не использовали термин пользовательская история, но по сути отвечали на вопросы «Кто наш клиентЭ», «Как он пользуется нашим сервисомЭ» и «Зачем ему наша услугаЭ» Информация получена из обращений клиентов, поступающих на наш сайт, а также из личного общения с теми клиентами, которые заказали и не заказали наши услуги (услуги перевода).
Александр Грицай, генеральный директор компании «Прогноз СЕЙЧАС!» Мы используем методологию выявления потребностей клиентов с помощью обратной связи, опросов, живого общения (у нас сложный B2B-продукт, а количество клиентов измеряется десятками), ранжируем их, расставляем приоритеты для спринта по критериям полезности для текущего и будущего.
пользователей и выпускать для них обновления раз в месяц.
Ольга Книга, сооснователь и генеральный директор Merku.ru Мы используем их, как любой инструмент – когда это необходимо.
Прежде всего, при разработке лендинга и новых функций продукта.
Согласны ли вы с утверждением, что техника пользовательских историй подходит только для agile-команд? Александр Богомолов, экс-менеджер проекта «ПоискСтройек» Я не очень понял вопрос — что мешает созданию историй любой командой? Да — в проектах со строгим техническим заданием истории на первый взгляд не очень нужны, но они помогают превратить такую разработку в более осмысленную.
Они помогают понять, почему вообще реализована та или иная функция.
Леонид Тощев, технический директор Datamonkey Сейчас понятие Agile стало настолько размытым — мне кажется, что не существует компаний, которые не были бы agile. Соответственно, пользовательские истории могут использовать все желающие.
Мария Теркина, сооснователь и генеральный директор Globeland Я думаю, что пользовательские истории вписываются в гибкий подход, но их также можно использовать и в других подходах к разработке.
Мария Подоляк, сооснователь Gagarin Labs Подход к проектированию функциональности продукта или интерфейса с использованием пользовательских историй изначально не является Agile-разработкой.
Так называемые usecases (нас-кейсы, примеры использования) уже давно существуют в практике разработки технических заданий.
Подход тот же, слегка измененный под нужды Agile. В приватных разговорах двух продакт-менеджеров можно услышать: «Ой, мы начали делать новый продукт для распознавания окраса кошек на фотографиях!» В ответ можно услышать: «Дайте нам дело».
Мы говорим в пользовательских историях, потому что только так можно понять, какая «боль пользователя» решается, какой инновационный или радикально иной способ решения проблемы используется и как это происходит на функциональном уровне.
История помогает «примерить» решение на себя.
Пользовательские истории также используются при проектировании интерфейсов.
С этим подходом я познакомился в Школе дизайна интерфейсов.
Мы рисовали портрет пользователя (их иногда называют персонами), писали сценарий истории, затем вырезали из бумаги интерфейс, чтобы разыграть сценарий или историю (так проверялась гипотеза).
В ноябре я попробовал применить тот же подход к разработке контент-стратегии компании или продукта на семинаре в Школе интернет-маркетинга в Нижнем Новгороде.
И это сработало великолепно.
Так что подход применим ко всему в продукте: функционалу, интерфейсу, маркетингу и т. д. Заставляет думать «головой пользователя», понимать его проблему, а не впадать в галлюцинации.
Таким образом, Agile не сделал ничего нового, он просто адаптировал существующий подход под свои нужды.
Ольга Книга, сооснователь и генеральный директор Merku.ru Техника пользовательских историй подходит не для команд, а для конкретных случаев и историй — когда можно выделить достаточно стандартного пользователя, который будет представлять типичную группу.
Еще один полезный способ их использования — вернуться к пониманию того, для кого делается проект: для команды или отдельного человека, который начинает строить асфальтоукладчик с вертикальным взлетом и отвлекается от контекста решения задачи для конкретного человека.
группа людей.
Помимо пользовательских историй, мы проанализировали и другие материалы Gov.uk (с комментариями российских экспертов):
Дизайн продукта, ориентированный на пользователя Основные аспекты методологии Agile Теги: #пользовательские истории #GTD #agile-
Как Воспитать Наследника В Своем Бизнесе?
19 Oct, 24 -
Вперед В Прошлое…
19 Oct, 24 -
Управление Голосом Или Правильным Сообщением
19 Oct, 24
