User story что это

User story на отлично: что учесть, чтобы написать хорошие требования к ПО

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

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

Привет, меня зовут Алёна, я бизнес-аналитик в Red Collar. В этой статье я собрала частые ошибки при написании критериев приемки к пользовательской истории. Предлагаю советы, которые стоит учесть при при разработке требований.

1. Идём от общего к частному

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

Антипример: На первом созвоне с клиентом выяснять, какого цвета кнопку «Купить» он хочет видеть на сайте своего магазина.

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

2. Не используем в требованиях слова, отражающие субъективную оценку (небольшой/хороший/яркий и т д)

Антипример: «Заголовок должен быть кратким».

Пример: «Заголовок должен быть длиной не более 20 знаков с пробелами».

3. Описываем подробности только по согласованию с заказчиком, дизайнером и разработчиком. Если не знаем — ставим «TBD (To Be Determined)» и идем узнаем

Антипример: «При нажатии кнопки “Создать заказ” открывается всплывающее окно розового цвета с фанфарами и песней Валерия Меладзе на фоне».

Пример: При нажатии кнопки «Создать заказ» появляются поля создания заказа. Формат TBD.

4. Дотошность и внимательность — главные друзья БА

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

Важно внимательно вычитать все скопированное и убрать «лишние» слова из других требований. В работе БА количество требований и скорость их написания ничего не значат, если в итоге в требованиях много ошибок и опечаток, которые могут повлиять на разработку конечного продукта.

5. Пишем названия юзер стори (чтобы при беглом взгляде на заголовок понять, о чем речь)

Антипример: User Story №1. Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить онлайн заказ.

6. Не смешиваем разные функциональности

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

Антипример: В US про регистрацию написать: «После нажатия кнопки “Зарегистрироваться” открывается личный профиль клиента. Профиль состоит из …».

7. Не дублируем одну и ту же информацию

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

Антипример: Повторно описывать правила валидации параметров, которые уже были описаны в другой US.

Пример: Сослаться на другую US или сделать отдельную страницу для всех валидируемых полей и всегда ссылаться на нее.

8. Описываем результаты как положительного сценария, так и отрицательного

Антипример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа».

Пример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа. При заполнении хотя бы одного поля не в соответствии с правилами валидации после нажатия кнопки “Создать” появляется сообщение об ошибке. Возможный текст:…».

9. Добавляем диаграммы, схемы, вайрфреймы, но только если они несут ценность для понимания данной US

У оформления критериев приемки нет четких правил. Вы можете описывать функциональность, как считаете нужным, но только если это действительно важно для понимания принимающей стороной

Антипример: «US1 Регистрация. Диаграмма движения популяции морских котиков прилагается».

Пример: «US1 Регистрация. Диаграмма процесса регистрации с учетом интеграций со сторонним сервисом прилагается».

10. Добавляем ссылку на дизайн или прототип, обновляем по мере готовности

Антипример: Мысли разработчика при виде требований без ссылок на визуал: «Гора текста, ниче не понятно, еще и картинки нет».

Пример: Мысли разработчика при виде требований со ссылками на прототип: «Гора текста, ниче не понятно, хоть картинка есть, слава Богу».

11. Всегда думаем головой в каждом конкретном проекте

Антипример: «В статье читал(а), что можно только так, поэтому лучше напишу, как там было указано».

Пример: «Автор статьи не видит этот конкретный проект и, если мне кажется, что здесь стоит применить другой подход, но я не уверен(а), стоит посоветоваться с коллегами».

Выводы: всегда есть место развитию

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

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

Что такое пользовательская история?

Так вот, пользовательские истории! Несомненно, это один из основных столпов 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 для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?

Размышления о написании пользовательских историй

Всем привет! Меня зовут Максим, и я работаю бизнес-аналитиком на проекте Швейцарских Железных Дорог. За последние пять лет я описал больше четырех сотен пользовательских историй, экспериментируя со структурой и форматом. Под катом рассказ о том, какие проблемы у меня возникали, и как их удалось решить.

Один из поездов Швейцарских ЖД

Важность и проблематика

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

Проблемы на этапе рефаймента

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

Проблемы на этапе разработки

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

Проблемы на этапе поддержки

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

Относительные затраты на исправление программных дефектов. Источник: исследование IBM Systems Sciences Institute.

Таким образом, можно уверенно сказать, что качественно написанная пользовательская история:

Сэкономит много времени и нервов команде разработки

Не снизит мотивацию разработчиков

Существенно сэкономит бюджет проекта

Развитие описания пользовательской истории в моих проектах

6 лет назад проект, в котором я тогда работал, решил перейти с Вотерфола на Скрам. Изучив методологию, было решено новые требования писать в виде пользовательских историй.

Начали мы с классического описания. Приведу вымышленный пример для понимания того, как это выглядело:

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

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

Первая реакция была — «Хмм, чего-то не хватает..» И действительно, методология Скрам предлагает писать истории простыми и лаконичными предложениями. В дополнении к этому необходимо написать критерии приемки, чтобы команда знала, как владелец продукта будет понимать, что история выполнена. Плюс можно расписать карточки пользователя, чтобы команда точнее понимала особенности и потребности пользователя (про карточки в контексте выглядит лишним, и их нет в примере). Ну хорошо, давайте добавим:

Пример доработанной пользовательской истории

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

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

Пользователь может изменить свой почтовый адрес

*представитель цифрового поколения

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

Описание функциональных требований

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

Пример пользовательской истории с функциональными требованиями

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

Системный дизайн

FR.NAME.123.01 Система должна предоставлять возможность пользователю менять свой почтовый адрес

Новая кнопка «сменить адрес доставки» должна быть добавлена на форме информации о пользователе

FR.NAME.123.02 Система должна предоставлять возможность хранить адрес доставки заказа отдельно от текущего адреса пользователя

Новый атрибут «адрес» должен быть добавлен на объектный тип Заказ

Когда курьер забирает заказ, система должна копировать адрес пользователя в Заказ.адрес.

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

Пользователь может изменить свой почтовый адрес

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

Для того чтобы не запутаться и удобнее было обсуждать требования вводятся идентификаторы.

Истории-энейблеры

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

Пример неудачной пользовательской истории-энейблера

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

Описание бизнес-предпосылок

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

Пример описания бизнес-предпосылок

В Марте наши маркетологи решили разработать новую программу доставки «Срочный заказ», что, по их мнению, позволит повысить удовлетворенность пользователей на 12%. Для того чтобы внедрить программу, необходимо помечать все заказы уровнем срочности. Старым заказам в базе нужно присвоить срочность «Обычная».

Разработка через поведение

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

Смысл подхода заключается в том, чтобы в понятной для всех сторон форме описать поведение системы. Фокус именно на поведении, а не на требованиях и бэкграунде позволяет определить те редкие сценарии, которые упускались ранее при обычном анализе и рефайменте. Работает это довольно просто: сначала аналитик (владелец продукта или член команды разработки, анализирующий историю) определяет бизнес-правила, которые применимы к описываемой функциональности. После чего покрывает эти правила примерами использования. А затем организует встречу трех друзей (Tres Amigos), на которой каждый из представителей бизнеса, разработки и тестирования оценивает правила и примеры со своей точки зрения. Владелец продукта убеждается, что все бизнес- потребности закрыты или отклоняет примеры с заведомо нерелевантными бизнесу сценариями. Разработчик убеждается в том, что все примеры применимы к текущей реализации системы и выбранному решению. Тестировщик же накидывает самые неочевидные сценарии, тем самым избавляя историю от пробелов в дизайне.

Три друга. Церемония по выявлению поведения системы.

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

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

Бизнес-бэкграунд

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

Системное поведение

BR.NAME.123.01 Система позволяет сменить адрес, если заказ еще не в доставке

EX.NAME123.01.01 Тот, в котором пользователь успешно меняет адрес, если заказ еще не у курьера

EX.NAME123.01.02 Тот, в котором пользователь не может изменить адрес, так как заказ уже у курьера

BR.NAME.123.01 Новый адрес должен быть в зоне доставки

EX.NAME123.02.01 Тот, в котором система разрешает изменить адрес, так как он в зоне доставки

EX.NAME123.02.02 Тот, в котором система запрещает изменение адреса, так как он вне зоны доставки

Системный дизайн

FR.NAME.123.01 Система должна предоставлять возможность пользователю изменять свой почтовый адрес

Новая кнопка «сменить адрес доставки» должна быть добавлена на форме информации о пользователе

FR.NAME.123.02 Система должна предоставлять возможность хранить адрес доставки заказа отдельно от текущего адреса пользователя

Новый атрибут «адрес» должен быть добавлен на объектный тип Заказ

Когда курьер забирает заказ, система должна копировать адрес пользователя в Заказ.адрес.

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

Пользователь может изменить свой почтовый адрес

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

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

Ориентирование на клиента

Новая структура зарекомендовала себя, и мы решили поделиться результатами применения нового подхода с другими командами в проекте на ближайшем общем аджайл-митапе. Опыт использования нового формата был представлен в рамках доклада о культуре рефаймента и ее развитии. В результате оживленной дискуссии, один из наших швейцарских коллег указал на очевидный минус такого подхода — слабую реализацию принципа ориентирования на клиента (customer centricity). Подобная структура истории, хоть и вполне выполняет свои функции, не имеет описания со стороны клиента. Не показывает его проблемы, боли и желания. И как следствие, на дает разработчику возможности понять особенности ситуации глазами пользователя.

Чтобы устранить проблему слабого описания со стороны клиента необходимо «вернуться на круги своя» и добавить в существующий формат изначально удаленное нами классическое описание пользовательской истории.

Пример истории с учетом ориентирования на клиента

История использования

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

Бизнес-бэкграунд

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

Системное поведение

BR.NAME.123.01 Система позволяет сменить адрес, если заказ еще не в доставке

EX.NAME123.01.01 Тот, в котором пользователь успешно меняет адрес, если заказ еще не у курьера

EX.NAME123.01.02 Тот, в котором пользователь не может изменить адрес, так как заказ уже у курьера

BR.NAME.123.01 Новый адрес должен быть в зоне доставки

EX.NAME123.02.01 Тот, в котором система разрешает изменить адрес, так как он в зоне доставки

EX.NAME123.02.02 Тот, в котором система запрещает изменение адреса, так как он вне зоны доставки

Системный дизайн

FR.NAME.123.01 Система должна предоставлять возможность пользователю изменять свой почтовый адрес

Новая кнопка «сменить адрес доставки» должна быть добавлена на форме информации о пользователе

FR.NAME.123.02 Система должна предоставлять возможность хранить адрес доставки заказа отдельно от текущего адреса пользователя

Новый аттрибут «адрес» должен быть добавлен на объектный тип Заказ

Когда курьер забирает заказ система должна копировать адрес пользователя в Заказ.адрес.

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

Пользователь может изменить свой почтовый адрес

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

Выводы

За все время экспериментов с форматом пользовательских историй я сделал для себя несколько выводов.

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

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

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

Желаю всем успехов в написании пользовательских историй! Если у вашей команды есть интересные практики и техники описания — буду рад увидеть их в комментариях.

Как писать User Story

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 Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность продать их другим пользователям.

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

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

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

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

Как вы до сих пор справлялись с подобными задачами?

ДИНАМИКА ЗНАНИЙ

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

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

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

ЧТО ДАЛЬШЕ?

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

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

Как работать с user story

Бывает так, что при разработке IT-решений команды опираются лишь на техническое задание, не обсуждая будущий продукт с пользователями (подробнее о UX-интервью — в этой статье). Однако, в этом случае есть риск, что продукт не решит в полной мере проблемы последних и даже может создать для них новые «боли».

Для снижения этого риска важно продумать User story — сценарии работы пользователей с продуктом.

User story — это короткая история с описанием возможных вариантов применения продукта. Как правило, её совместно создают UX-дизайнеры, продуктовые дизайнеры или аналитики на этапе планирования разработки и развития проекта, при необходимости подключая заказчика.

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

В user story необходимо определить:

— Цели пользователей. Расскажите, какие цели на самом деле преследуют пользователи при работе с продуктом.

— Результаты. Опишите, какие действия пользователь может выполнить при работе с продуктом.

При создании user story обычно используют доску с цветными стикерами, программы Miro или FigJam. Для того чтобы быстро ориентироваться в стикерах, используйте различные цвета для каждой строки, обозначающей действия, шаги и иные сведения. Далее рассмотрим этот процесс подробнее, опираясь на классические рекомендации Джеффа Паттона из книги «Пользовательские истории. Искусство гибкой разработки ПО».

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

User story описывает роль пользователя в продукте, его потребность и результат, который он получит, если событие произойдет. Для быстроты составления используется следующий шаблон:
“Я как (тип пользователя), хочу (действие или цель пользователя), чтобы (получить следующий результат или выгоду)”.

Рассмотрим на примере заказа дебетовой карты в онлайн-банке:

Я как пользователь online банка могу заказать дебетовую карту, чтобы не тратить время на поход в отделение.

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

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

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

Так как история может иметь разветвления, в схему нередко добавляются прочие активности и роли персонажей. Мы разделили схему на 3 активности, а именно:

ознакомление с услугой;

первый вход в онлайн-банк;

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

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

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

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

Пользовательские истории в разработке

Пользовательская история (User story) описывает тип пользователей, чего они хотят и почему. Этот инструмент помогает создать упрощенное описание требований, но при этом таковым не является. Требования — это другой инструмент, с более сложной структурой и описанием.

Обычно User story используют при разработке по методологии Agile. Ранее мы писали, как происходит работа при гибком подходе. На этапе дискавери-фазы обычно разбивают разработку продукта на пользовательские истории, а не на характеристики или требования.

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

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

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

Как [описание пользователя ], я хочу [ функциональность ], чтобы [ выгода ].

Детально рассмотрим шаблон:
Описание пользователя. Кем является человек по ту сторону экрана? Личность пользовательской истории не обязательно должна ограничиваться должностью человека. Например, руководителем удаленной команды может быть как и менеджер отдела, так генеральный директор, или любое другое лицо в компании. При построении истории мы должны понимать как думает и работает этот человек, знать его намерения. В идеале у пользователей нужно провести интервью.

Функциональность. Здесь описывается не сама фича, а намерения людей, каких целей они хотят достичь.
Выгода. Для чего пользователи совершают все эти действия? Описываем конечную выгоду и проблемы, которые хочет решить выбранная личность.

На практике пользовательские истории могут выглядеть так:

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

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

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

Насколько детальной должна быть User Story?

В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

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

Рассмотрим Agile-подход к решению этой проблемы.

Для начала разберемся с концепцией CCC, которая расшифровывается как Card, Conversation, Confirmation.

Card (Карточка)

Идея состоит в том, что вся User Story должна поместиться на небольшую бумажную карточку или стикер. Много на ней не напишешь, да это и не нужно.

Главное предназначение карточки – служить напоминанием, приглашением к обсуждению (placeholder for conversation).

Цель – сместить фокус с написания требований на их обсуждение. Ибо живое обсуждение более важно, чем написанный текст.

Карточка должна коротко, но емко отражать суть задачи. Предлагаемый формат:

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

При написании User Story рекомендуется сосредоточиться на пользователе нашего приложения (focus on user needs and benefits).

Функциональность лучше описывать не абстрактно, а с использованием живых примеров (by example).

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

User Story может ссылаться на развернутые требования, например, протокол взаимодействия или формулу расчета.

Карточка User Story служит также для отслеживания статуса задачи, например, на канбан-доске.

Conversation (Обсуждение)

Обсуждение – наиболее важная часть.

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

Общение, в идеале, происходит лицом к лицу (face to face), так как это наиболее эффективный (high bandwidth) способ передачи информации. Важные аспекты живого общения – это его интерактивность (возможность уточнить и удостовериться), а также обратная связь (один из фундаментальных принципов Agile).

Живое обсуждение позволяет преодолеть или свести к минимуму недостатки, присущие документации:

Confirmation (Подтверждение)

Третий важный аспект User Story – это подтверждение того, что задача выполнена.

Условия приемки (acceptance criteria), а также Definition of Done, оговоренные заранее, позволят вовремя прекратить работу, оценить, достигнута ли преследуемая бизнес-цель.

Для подтверждения задачи agile-команда проводит демонстрацию новой функциональности заказчику, собирает замечания, получая оперативную обратную связь.

Насколько же детальной должна быть User Story?

Вернемся к исходному вопросу и рассмотрим две крайности:

Очевидно, что мы не хотим впадать ни в одну из этих крайностей. Значит оптимум где-то посередине. Чтобы нащупать его, будем использовать концепции “точно вовремя” (just in time) и “ровно столько, сколько нужно” (just enough).

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

Можно ли достичь такого баланса для каждой User Story? Разумеется нет, но надо постоянно подстраиваться.

Поделитесь, пожалуйста, в комментариях, как вы работаете с User Stories. Актуальна ли для вас описанная проблема? Какие другие проблемы, связанные с User Stories, возникают в вашей команде?

Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.

Идеи данной статьи почерпнуты из следующих источников:

User story или история пользователя

Что такое user story? Для чего она нужна? И как “рассказать” правильную историю?

Началось это еще лет эдак 8 назад, когда я учился в институте… Стоял прекрасный солнечный день, солнышко светило в окошко, а настроение приближающегося лета питало мои надежды на скорое завершение учебного дня. Так…стоп, не об этом история, попробуем еще раз.

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

Чтобы понять, как лучше решить ту или иную “боль” вы должны представлять себе сценарий или ситуацию, в которой находится человек с определенной потребностью. Вот тут и появляется история пользователя.

Что такое история пользователя (user story)

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

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

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

Какие задачи решает user story

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

Как писать user story

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

По существу, чтобы заполнить форму, вам необходимо:

Конечно, user story вы можете сочинить и сами, но вот вопрос, зачем? Так как главная задача метода, это решить самые наболевшие проблемы, то для начала вам необходимо их определить, а потом уже сформировать user story. Предлагаю небольшую схему того, как должна создаваться история пользователя.

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

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

Давайте перейдем к конкретным примерам и поймем как же это работает.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример истории пользователя: эмоджи

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

Понимаю, как тяжело это представить…

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

Вас посещает идея, что неплохо бы удивить их чем-нибудь. Вы формируете историю пользователя:

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

Я как пользователь социальных сетей, хочу эмоджи, так как мне скучно.

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

Если историй много

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

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

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

Не забудьте про измерения

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

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

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

Два основных вопроса для критериев приемки:

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

История пользователя, это один из мощнейших инструментов для создания нужного продукта. Используйте его в своих проектах, общайтесь с пользователями и будьте открыты для изменений. А главное запомните, много историй не бывает, хороших историй пользователя тем более 😉

Интересный ролик от компании Under Armor, атмосферное и заряженное видео.

Что такое user story и как ее писать?

User Story переводится с английского как «пользовательская история». Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика.

Само название — user story — указывает, что этот документ имеет формат истории и излагается в повествовательной форме.

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

Шаблон user story

Юзер стори пишется по шаблону «Как [пользователь], я хочу […], чтобы […]». В таком формате поясняется, что именно хочет пользователь или заказчик, и почему.

Рассмотрим этот шаблон подробнее.

Отличие user story от спецификаций и сценариев использования

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

Как писать user story?

Пользовательская история должна быть написана грамотным языком.

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

Практические советы по написанию user story

Модель INVEST

INVEST — слово, использующееся для запоминания критериев качественной истории:

Итоги

User story — максимально понятное описание функционала продукта, его особенностей и пользы для конечного пользователя. Польза user story в том, что она помогает разработчику лучше понять продукт и целевую аудиторию заказчика. Для проверки качества истории используются INVEST-критерии.

User Story — инструкция по применению

Как правильно формулировать пользовательские истории? Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.

User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него.

Для чего применяется User Story?

Как формулировать User Story?

User Story — это ответы на 3 вопроса, связанные в одно предложение:

Как ,

я хочу/могу ,

Описания продуктовых практик и подходов, сгруппированные по 7 темам, от Дмитрия Кустова

Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.

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

И ещё немного примеров:

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

Хорошая пользовательская история

INVEST — критерий хорошей истории:

Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки

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

Мы учим формулировать User Story на тренинге «Владелец продукта: краткий курс выживания».

P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.

Подключайтесь к Telegram-каналу, где Дмитрий делится практиками и опытом.

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 stories are not requirements» автора Пер Лундхольм (Per Lundholm).

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

А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа «требования в бэклоге» сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования — пользовательскими историями, и вот мы уже «agile»…

Еще один признак возможного недопонимания — распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.

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

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

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

И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника «Specification by Example». Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес — правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что – то пойдет нет так вследствие внесения изменений — нарушение какого бизнес — правила явилось причиной данной дисфункции.

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

Контракт

(автор Маттиас Скарин)

Итак, что мы будем использовать вместо спецификации требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile – контракты. Agile — контракты — это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.

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

Как правильно писать User Story

О том, как правильно писать User Stories, будет рассказано в представленной статье.

Что такое User Story и кому она необходима

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

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

Как правильно писать User Story

Сбор информации для User Story проводится при помощи количественных и качественных исследований (интервью, опросов, изучения фокус-групп) и определения наиболее актуальных и «больных» потребностей пользователя. Этот процесс может выглядеть как:

беседа с заинтересованными лицами (пользователями, клиентами, разработчиками, тестировщиками), в ходе которой составляется необходимая документация;

оформление рабочих карт или записок, содержащих задачи по написанию User Story;

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

Чтобы правильно написать User Story, необходимо:

получить ответы от пользователей на заданные им вопросы;

разбивать крупные истории на несколько небольших (со сроками создания в 1-2 дня) с четким детальным описанием конкретных задач;

прописывать в User Story критерии приемки для простоты тестирования соответствия готового продукта требованиям пользователей;

использовать для User Story в дизайне скетчи или наброски.

ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ приглашает всех желающих научиться писать User Story. Записаться на данные курсы можно на нашем сайте.

User story что это

User story (пользовательская история) считается одним из самых простых способов описания бизнес-требований. Многие считают именно user story главным инструментом для продакт-менеджера: это помогает ему простыми словами объяснить разработчикам, что и зачем должно быть сделано.

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

Шаблон для пользовательской истории выглядит так:

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

На этом этапе начинающие продакты устраивают праздник. Для них обучение закончено, они идут ставить первые задачи команде. Команда в шоке.

Примеры таких историй:

Разберем ошибки:
а) Оператору колл-центра не важно, какой признак передаётся в системе. Ему важно отображение статуса заказа на карточке клиента или карточке заказа, потому что он будет использовать в работе пользовательские интерфейсы, а не технические логи.

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

Ошибки:
а) Что должно происходить при нажатии кнопки? Куда она ведёт?

в) Добавить кнопку вместо имеющейся? Или на карточке должно быть две кнопки? Это уже придирка, но об этом тоже было бы неплохо подумать при формулировке user story.

К этой истории есть один комментарий, но он очень важный:
А не проще ли передать это требование складу в виде инструкции или распоряжения и отправить им подарки, предназначенные для вложения в заказ? История выглядит так, будто разработка не нужна совсем.

Ещё Майк Кон, известный во всём мире agile-коуч, говорил, что «пользовательские истории не являются конечными требованиями к системе, и не предназначены быть полезными в конце итерации» (в книге «User stories applied»). В первую очередь, пользовательские истории нужны для того, чтобы выяснить, что нужно клиенту. Так ищутся основные боли пользователя и возможные способы их исправления.

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

И даже после нескольких таких итераций пользовательские истории могут нуждаться в улучшении. Проверить это можно с помощью метода INVEST:

Пример хороших user stories:

Пример 1:
Как куратор онлайн-курса, я хочу знать имя и контакты заинтересовавшихся курсом посетителей сайта, чтобы направить им по e-mail информацию о старте курса.

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

Гайд по User Stories для Junior BA / PO / PM

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

Содержание:

Вводная информация о User Stories

Что такое User Stories

Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.

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

В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».

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

Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:

Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!

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

Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.

Так, истории пишутся в три строки:

Job Stories

В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.

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

«Тело» JS делится на три части:

Job Stories могут писаться по двум форматам:

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

Вопросы, которые следует задавать во время написания стори

А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».

Пример работы техники «5 почему».

Три С в User Story

Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».

User Personas

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

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

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

Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:

Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.

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

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

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

Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.

Отрицательный персонаж

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

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

Ключевой персонаж

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

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

INVEST

По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.

I — Independent — Независимый

Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).

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

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

N — Negotiable — Обсуждаемый

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

V — Valuable — Ценный

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

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

E — Estimable — Оцениваемый

История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:

Однако подробнее об оценках поговорим в отделе “Оценка историй”.

S — Small — Компактный

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

T — Testable — Тестируемый

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

Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.

Как добавить деталей к истории?

Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.

Acceptance Criteria

Что такое АС

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

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

Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.

Что делать, когда надо выбрать одно из нескольких решений?

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

Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:

1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.

Gherkin

Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»

Базовый синтаксис Gherkin

Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see

2) Создается таблица с примерами.

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

User Story: план действий для разработчика

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

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

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

Что такое User Story?

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

Три довода в пользу User Story по сравнению с спецификациями при разработке мобильного приложения:

Как было сказано выше, правильно написанная пользовательская история позволяет избежать множества распространенных проблем, главная из которых — неправильное представление конечного продукта разработчиком. Ситуация, кстати, достаточно распространенная. И в интересах издателя, чтобы результат разработки мобильного приложения полностью соответствовал требованиям и ожиданиям пользователя, а значит, созданию User Story следует уделить особое внимание.

Какие требования выдвигаются к написанию пользовательских историй?

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

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

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

В качестве… (описание представителя ЦА, его роль в приложении), он получает… (действия в приложении) для… (цели его действий в приложении).

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

Окончательная формулировка истории должна быть лаконичной и точной. Если сформулированная заказчиком история содержит сложные расплывчатые понятия, ее следует переписать. В идеале User Story должна быть:

Рекомендации для написания правильных User Story

Что делать не стоит?

Необходимо отметить, что User Story не является чем-то нерушимым и не приемлющим каких-либо изменений. В принципе, при необходимости заказчик может добавлять новые пользовательские истории, менять приоритеты и т.д. Это вполне допустимо. При этом разработчик со своей стороны обязан объяснить заказчику, чем чревато будет предложенное изменение или добавление. Живое общение на этой стадии — залог успеха в будущем. Ведь создание успешного мобильного приложения – это блестящая идея + не менее блестящее ее воплощение. А для последнего значение правильно написанной User Story вряд ли можно переоценить.

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

Анна Минникова, Гиперболоид, сертифицированный 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 нужно стараться придерживаться максимально простого описания (без ухода в технические детали). Учитывать роли пользователей при работе с продуктом. Стараться не увеличивать размер истории. Она должна вписаться в одну итерацию, которая при гибких методологиях длится не более двух недель.

Заменяем User Story на Job Story

Всем привет. Перевели еще один интересный материал для студентов курса «Product Manager IT-проектов». Приятного прочтения

Раньше, я уже писал о проблемах с user story (пользовательскими историями). В те времена я считал, что лучше просто попросить команду обсудить предлагаемые изменения в продукте. Стратегия была хорошей, если команда оказывала помощь, а продукт был уже зрелым. Однако теперь я работаю с новой командой и создаю продукт с нуля. В таком случае перед нами лежит чистый лист и нам непросто прийти к согласию, когда речь заходит о мотивации клиентов, событиях и ожиданиях. На сегодняшний день все изменилось. Я нашел отличный способ использовать философию Jobs To Be Done, чтобы определить функционал продукта. Сегодня мы поговорим о Job Stories.

Откуда она взялась

Эта идея пришла от очень умных ребят из Intercom. Вот что они говорят на этот счет:

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

Когда _____, я хочу______, чтобы_______.

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

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

Сегодня мы не будем тратить много времени на пояснение концепции, я просто расскажу о том, почему она мне нравится и почему она лучше, чем User Story.

О проблеме User Story [еще раз]

В целом, проблема пользовательских историй состоит в том, что они содержат слишком много предположений и мало причинно-следственной связи. Когда задача ставится в формате пользовательской истории (Как [тип пользователя], я хочу [действие], чтобы получить [результат]), отсутствует место для вопроса «почему?», по сути вы просто ограничиваетесь определенной последовательностью, вырванной из контекста.

Вот как я вижу этот формат:

Предположения и отсутствие связи между человеком и его действием.

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

Давайте посмотрим на некоторые существующие пользовательские истории:

Пример того, как пишутся User Stories

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

Вот, попробуйте. Уберите всю часть «как [тип пользователя]» и посмотрите, действительно ли вы что-то теряете. Сравните следующие высказывания:

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

Или же:
Я хочу создать новую игру, введя название и необязательное описание.
Неужели небо рухнуло?

Job Story: Все о контексте и причинно-следственной связи

Формат Job Story

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

Посмотрим еще раз на изображение и наконец начнем!

Вся вышеприведенная информация очень важна и информативна, поскольку мы фокусируемся на причинно-следственной связи. Каждая Job Story должна содержать как можно больше контекста и фокусироваться на мотивации, а не только на реализации.

Проработав с Job Story некоторое время, я поменял «Мотивации» на «Мотивации и действующие силы». Взгляните на статью «5 советов для написания Job Story», где эта тема затрагивается непосредственно. Больше о действующих силах вы можете в этом подкасте и маленькой статье.

Давайте перепишем в Job Story некоторые примеры из таблицы пользовательских историй, которая была приведена выше, добавив к каждой мотивацию и контекст.

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

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

User Story:
Как модератор, я хочу выбрать предмет для оценивания или переоценки, команда видит этот предмет и может оценить его.
Job Story:
Когда у предмета нет оценки или оценка мне не нравится, я хочу иметь возможность заново запустить процесс оценки и уведомить всех, чтобы команда знала, что определенный предмет требуется оценить.

Как насчет нескольких ролей и событий?

Поскольку я получаю различные отзывы о Job Story и продолжаю с ними работать сам, я считаю целесообразным иногда включать некоторые роли или персонажей в часть Когда _____.

Продукты с несколькими ролями

Роли и персонажи наиболее полезны, когда сам продукт имеет несколько ролей, например IT-продукт (администратор, менеджер, участник) или товар с открытого рынка (покупатель, продавец). Причина и в том, что нужно всегда понимать, о ком мы говорим.

Возьмем в качестве примера eBay:

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

Роли и причинно-следственные связи

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

И снова возьмем в пример eBay:

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

Использование событий вместо ролей

Иногда может возникнуть ситуация, когда событие влияет на все роли или группы людей: например, необходимо получить напоминание о пароле. В этом случае нет никакой причины вводить определенную роль, вместо этого ее нужно оставить на уровне общих понятий, например «клиент» или нечто подобное (но не «пользователь»):

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

Почему не пользователь? «Пользователь» звучит очень безжизненно и бесплодно, тогда как «клиент» напоминает вам о том, что есть люди, которым вы должны предоставить услугу и которых нужно уважать.

Определите мотивацию, а не реализацию

Job Stories хороши тем, что они заставляют нас думать о мотивации и контексте, а также снимают акцент с добавления какой-либо конкретной реализации. Часто из-за того, что люди сосредотачиваются на вопросах «кто» и «как», совсем забывая про «почему». Когда вы начинаете задумываться о «почему», ваш ум открывается для творческих и оригинальных способов решения проблемы.

User story что это

User Story [пользовательские истории] — это, пожалуй, самая популярная техника для определения рамок функциональности продукта. Работать с историями легко. Но рассказать хорошую историю может быть сложно. Эти 10 советов помогут вам создавать хорошие истории.

Пользователи на первом месте

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

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

Используйте Персонажей для поиска правильных историй

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

Создавайте истории командой

Пользовательские истории — это простая методика, которая позволяет двигаться быстро. Это не спецификация, а скорее инструмент совместной работы. Истории никогда не должны отдаваться на откуп команде разработчиков. Напротив, они должны рождаться в процессе обсуждения: Менеджер по продукту (The Product Owner) и команда должны обсуждать истории вместе. Это позволяет фиксировать минимальную необходимую информацию, уменьшать издержки и ускорять процесс.

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

Если вовлечь команду разработки нельзя, подумайте над использованием другой техники для определения функциональности продукта — Use Cases (кейсы использования продукта).

Составляйте короткие и простые истории

Пишите истории, которые легко понять. Составляйте их простыми и краткими. Избегайте сбивающих с толку и двусмысленных понятий, используйте действительный залог. Фокусируйтесь на том, что важно и убирайте все остальное. Шаблон ниже превращает пользователя или покупателя в персонажа истории и позволяет объяснить его выгоды. Он основан на популярном шаблоне Рейчел Дейви, но я заменил «роль пользователя» на «имя персонажа», чтобы связать историю с релевантным персонажем.

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

Начните с поэмы

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

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

Совершенствуйте истории, пока они не будут готовы

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

Добавьте критерии успеха

По мере того, как вы делите поэму на мелкие истории, помните, что к каждому из них должен быть добавлен критерий успешности. Он дополняет рассказ: позволяет описать условия, которые должны быть выполнены для того, чтобы история завершилась. Этот критерий дополняет историю, делает её измеримой, а также позволяет продемонстрировать историю, выпустить её для пользователей или инвесторов. Как правило, я использую от 3 до 5 критериев для каждой детальной истории.

Используйте бумажные карточки

Пользовательские истории возникли из Экстремального Программирования. А в Экстремальном Программировании говориться о «пользовательских карточках», а не об «историях». Тому есть простая причина: пользовательские истории записывались на бумажных карточках. У этого подхода есть три преимущества. Во-первых, бумажные карточки дешевы и их легко использовать. Во-вторых, это упрощает командную работу: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить полноту и целостность визуализации зависимостей. Даже если ваши истории хранятся в электронном виде, стоит использовать бумажные карточки, когда вы придумываете новые истории.

Держите сценарии на видном месте

Истории хотят сообщить вам информацию. Поэтому не прячьте их на сетевой диск, джунгли корпоративного интранета или в другие дебри. Определите их на видное место. Например, на стену. Это способствует командной работе, создает прозрачность процесса, делает очевидным, если вы добавляете слишком много историй слишком быстро (у вас просто начнет заканчиваться место). Удобный инструмент для поиска, визуализации и организации ваших сценариев — это доска продукта, показанная ниже.

Не полагайтесь только на истории

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

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

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

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

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

Действительно ли полезны пользовательские истории для разработчиков продукта?

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

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

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

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

Я очень надеюсь, что написание User Story войдет в бизнес-обиход в той же мере, что и определение целевой аудитории. Ещё 10 лет назад далеко не все клиенты могли сходу назвать свою ЦА.

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

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

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

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

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

«При решении задач пользователя стоит перенести фокус с персоны на контекст» Статьи редакции

Бывший менеджер продуктов «Яндекса» и автор Telegram-канала об управлении проектами Анна Булдакова о том, что такое концепция Jobs-to-be-done и как она помогает улучшать продукты.

Хочу рассказать про один классный фреймворк, о котором, к сожалению, знают немногие: Jobs-To-Be-Done (JTBD). Его популяризировал профессор Гарвардской школы бизнеса и автор «Дилеммы инноватора» Клейтон Кристенсен.

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

Пять минут назад Петя купил Sniсkers. Повлияла ли какая-то из характеристик, перечисленных выше, на факт покупки? Нет, не повлияла. Петя купил Snickers не потому, что ему 30 лет, а потому что он проголодался.

Конечно, идея строить продукт вокруг проблемы совсем не нова (собственно, и JTBD существует уже больше 30 лет, но применялся преимущественно в производстве физических продуктов). JTBD просто дает удобный фреймворк и инструментарий для работы, вот и всё. Но разница в организации команды, в построении стратегии и разработке фич — огромная.

Даже если вы не эксперт в UX, то наверняка встречали такой шаблон:

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

Честно, я несколько раз пыталась использовать персон и user stories в работе, но постоянно сталкивалась с одними и теми же проблемами.

Какие-то аспекты и вовсе могут сбить с толку: к примеру, мы делаем фичу «поделиться в соцсетях» для новостного сайта. То, что наша персона работает врачом, должно как-то повлиять на разработку фичи, должны ли мы это как-то учесть? Вот здесь у меня, например, начиналась трансформация what в why: а зачем вообще кому бы то ни было делиться нашими новостями в соцсетях? Что движет пользователем, какая у него мотивация? И, как ни странно, многие персоны при ответе на этот вопрос объединялись в одну группу.

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

Таким образом, мы плавно подошли к job stories, которые Intercom и изобрели. И смысл в том, что фокус с персональных характеристик тут смещается на контекст:

When I want to So I can ​

As a 30-летний Петя, I want to съесть что-нибудь вкусненькое, so that я больше не был голодным.

When у меня есть всего две минуты, чтобы перекусить между встречами, I want to съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови, so I can продержаться до обеда и сохранить рабочее настроение.

Разберем теперь более подробно, как составлять job story.

Например, у нас есть спортзал, где мы хотим увеличить продажи месячных абонементов. Сначала посмотрим на персон (описание довольно условно, в реальности оно более подробно и детализировано):

В каком случае такие описания будут нам полезны? Например, для таргетированной рекламы. Хотим мы привлечь больше Маш или Никит — пожалуйста: устанавливаем настройки кампании в соответствии с определенными характеристиками наших персон и ждем.

Годятся ли они для разработки, тем более, инновационной? На мой взгляд, не очень. Персона — это какой-то конечный результат исследований и нашего труда. Это та аудитория, которая у нас уже есть. Ориентируясь на персоны, мы искусственно ограничиваем свой продукт, не разрабатываем фичи для новых, потенциальных пользователей.

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

Условно говоря, мы можем построить суперсовременный спортзал с тачскринами и детским уголком, и при этом всё равно «подарить» часть пользователей мобильному приложению с тренировками или домашнему велотренажеру.

Вот пример job story, который мог бы случиться:

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

Важно ли тут, что Маше 30 лет? Что у нее двое, а не один ребенок? Кто она по образованию? И что вообще это Маша, а не Аня? Нет, на передний план выходит одна единственная характеристика: что у нашего пользователя есть маленькие дети.

В job stories это часть контекста, а не описания пользователя, просто потому, что в контексте могут оказаться совершенно разные по профилю пользователи. В примере с детьми это может быть Маша, а может быть и Никита, если его старшая сестра уехала в командировку и попросила посидеть с детьми, а он не хочет пропускать тренировку.

Легче всего это понять на примере Uber. Вроде как здесь-то уж точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот.

Если мы говорим про магазин сладостей, и контекст «Хочу изредка побаловать себя сладким после тяжелого дня или успешного проекта», то сюда могут попасть как Маша и Никита, так и диабетик Миша, вегетарианка Алиса и сидящий на диете Петя. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, те фичи, что мы делаем и реализуем, получают больший охват.

Персоны, безусловно, гораздо лучше, чем ничего. Более того, многие успешные компании до сих пор работают с этим фреймворком и прекрасно себя чувствуют. В любом случае, job stories — это лишь ещё один хороший способ с другой стороны взглянуть на свой продукт.

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

Допустим, мы прониклись и хотим написать хорошую job story. С чего начать? Конечно, с исследования.

Как писать качественные пользовательские истории

Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.

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

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

Но основная задача любой документации — выявить и описать потребности пользователя, для которого разрабатывается продукт. Она создана не столько, чтобы описать всё, что должен делать продукт, сколько чтобы убедиться, что команда знает, зачем пользователю продукт и как именно он будет им пользоваться. Невнимание к этой разнице в целях очень часто приводит к тому, что продукт работает «как написано», но не приносит никакой пользовательской ценности.

И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как я », позволяет команде задуматься над этой ценностью на самом раннем этапе.

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

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

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

Пользовательская история включает в себя следующие элементы:

Как писать пользовательские истории

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

Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.

Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:

Распространенные ошибки в пользовательских историях

История для пользователя

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

Что не так с этой историей? Все важные части, кажется, на месте, но присмотревшись ближе, мы не знаем, для кого мы проектируем эту историю. Возможно, наш пользователь — администратор системы, которому нужно премодерировать показ спецпредложений от рекламодателей? Или, возможно, он рекламодатель, которому нужно управлять показом спецпредложений в списке?

У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.

История для разработчика

Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»

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

Необходимо посмотреть на то, что делает библиотека Х для конечного пользователя продукта. К примеру, она позволяет быстрее создавать спецпредложения и убирает задержку после их создания. Тогда история может звучать так:

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

Перепишите ее с пользовательской точки зрения: «Как рекламодатель я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»

Технические заметки к этой истории могут выглядеть следующим образом:

При этом к такой истории гораздо проще написать критерии приемки:

Никакой бизнес-ценности для пользователя

Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».

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

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

Порочные практики

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

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

Перевес в пользу технических историй

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

UserStories это еще не все…

В рамках данной статьи хотелось бы поделиться личным опытом применения User Stories и рассказать об обогащении формата User Story — техникой 5 Whys, нацеленной на более глубокую проработку “цепочки создания ценности”.

UserStory — что это и как она выглядит…

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

Чем хороша User Story…

— для кого он делает инструмент — Actor?

— что ожидают от этого инструмента — Action?

— зачем будет использоваться этот инструмент — Reason?

Что необходимо для создания хорошейUserStory

Опыт использования показал, что для создания точных и содержательных User Stories необходимо проделать весь “стек” аналитической работы, т.е. применение легковесного формата не отменяет усилий аналитика по глубокому выяснению, описанию и анализу — пользователей, процессов, цепочек создания ценностей…

Следовательно, после того как выяснены Actors, написаны Scenarios, разработаны Use Cases, нарисованы диаграммы процессов, выяснены цепочки создания ценностей, можно взяться за создание содержательных, лаконичных и легковесных требований в формате User Stories, которыми вы будете оперировать при разработке решений.

Как можно расширить UserStory чтобы сделать ее более содержательной…

Хорошим заделом для разработки оптимального решения, по моему мнению, является — знание наиболее полной “цепочки создания ценности”.

Для того чтобы не вдаваться в подробности в данной статье об использовании техники 5 Whys, хотел бы дать ссылку на мой недавний труд — “5 Whys — как лекарство от Muda”, в котором эта техника рассмотрена на примерах.

В связи с выше изложенным, совмещение формата User Story и техники 5 Whys, для детализации “цепочки создания ценности” — позволяет наполнить разрабатываемые User Stories еще большим смыслом и дать возможность для разработки более продуманных и оптимальных решений.

Как использовать формат UserStory& 5 Whys…

Как менеджер, я хочу найти карточку клиента,

Заключение

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

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

Во-вторых: применение техники 5 Whys в рамках User Story, позволит более четко проработать и отразить “цепочку создания ценности”, что в свою очередь обезопасит вас от выполнения задач “цели которых вам не известны”, а более полное представление о “цепочке создания ценности” — может натолкнуть на разработку оптимальных решений для пользователей.

Информация об авторе:

(Аналитик, Командный Менеджер)

07 Октября, 2012

Похожие статьи:

Метод 5 Whys придуман выявления глубинных причин возникновения проблемы, а не для того, чтобы описывать «цепочки создания ценности».
То, что причины проблемы и «цепочка ценности» похожи, потому что их описание строится на основе причинно-следственных отношений, еще не повод применять 5 Whys для описания «цепочки ценности». Автор ошибается: «цепочки ценности» могут быть гораздо длиннее, чем пять. Кроме того, ценность может формироваться и куда более сложными структурами, чем цепочка, т.е., последовательность.

Уважаемый AndrewK, если вы прочитали статью на которую ведет ссылка — «5 Whys как лекарство от Muda», то вы должны были заметить, что автор не претендует на ввод своего личного «определения для техники 5Whys», а всего лишь — предлагает, применение этого инструмента для Бизнес Анализа (нестандартное применение). Так же никто не ограничивает применение этой техники цифрой «5″, но в большинстве случаев этого достаточно (так же как и для выявления ключевой проблемы, не всегда нужно «5 почему», все зависит от «качества» ответов получаемых при каждом вопросе «почему»).
Не очень понятно про «…ценность может формироваться и куда более сложными структурами, чем цепочка…» — хорошо бы увидеть пример?
Применение техники 5Whys, не ограничивает вас в «ветвлении — цепочек создания ценности/цепочек выявления ключевой проблемы», следовательно вы можете применять эту технику даже если на вопрос «почему/зачем» — вы имеете более одного ответа, просто для каждого ответа будет строиться отдельная «ветвь» (эти рассуждения, так же приведены в статье «5 Whys как лекарство от Muda»).
Благодарю за ваши комментарии и буду рад, если мои пояснения удовлетворят вас и других читателей!

Для моделирования причинно-следственных отношений существует достаточно много различных методов. Вот несколько:
— диаграммы Ишикавы, известные также как fish-back diagrams
— деревья текущей реальности в Теории Ограничений
— Root-Conflict Analysis Plus

Обращаю особое внимание на то, что все эти методы предназначены для выявления причин проблем. Метод 5Why — это наиболее простой в этом ряду. Посмотрите, хотя бы, правила проверки правильности модели, которые есть в других методах и нет в методе 5Why.

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

Но не в этом случае, когда вы предлагаете использовать метод 5Why для описания модели формирования ценности.

Во-первых, помимо «цепочек создания ценности» или Value Chain к типовым моделям, точнее, конфигурациям создания ценности, относятся также Value Shop и Value Network. Посмотреть можно хотя бы здесь: http://www.ctoupdate.com/ctoupdate-65-20070626ValueChainsNetworksandShops.html

Во-вторых, линейная структура метода 5Why (а ветвление не предусмотрено самим методом), никак не позволяет отразить более сложные конфигурации создания ценности. Более того, даже древовидная структура fish-back diagram не всегда позволяет отражать некоторые структуры формирования ценности.

Ну, и в-третьих, ваши замечания по-поводу того, что можно не только 5, или можно не только последовательность, означают, что вы предлагаете изменить метод. Но ваши идеи изменить метод приводят к его усложнению, следовательно, вы ухудшаете главное преимущество метода 5Why — его простоту (я бы даже сказал, святую простоту). А что при этом улучшается? Ничего. Тогда в чем смысл вашей идеи?

Во-первых, я хотел бы поблагодарить вас за конструктивную беседу и предложить вам начать делиться «своими знаниями» в более развернутом виде — например написать пару статей.

Во-вторых, хотел бы проявить немного «педантичности» и внести правки и уточнения в написанные вами строки, для тех читателей, которые захотят найти описание этих методик:
— Диаграмма Исикавы, а сам метод называется fishbone diagrams;
— Теория ограничений (Элия М. Голдратт);

Теперь попробую пояснить свою точку зрения и ответить на ваш вопрос.

Не могу согласиться с вашими строками «… Обращаю особое внимание на то, что все эти методы предназначены для выявления причин проблем. Метод 5Why — это наиболее простой в этом ряду…», так как метод «5 Whys» — предназначен для выявления корневой проблемы, а не на «выявление причин проблем». Хотя в свою очередь — метод fishbone diagrams — направлен именно на выявление причин возникновения уже сформулированной проблемы.
Но если честно, я не хотел бы глубоко вдаваться в это, так как цели статьи были немножко иными (как мне кажется, мы ушли в сторону «зациклившись» на одной фразе — «цепочка создания ценности» и на прямых назначениях методов). Теорию ограничений — даже не хочется затрагивать, так как перед ней стоят совершенно иные задачи — чем те «которым посвящена статья» =)

Первичная цель статьи — поделиться опытом «успешного» совмещения User Stories (как формата для формулировки требований) и техники «5 Whys» (в данном контексте — техника для выявления «цепочки создания ценности»). Слово «успешного», я применил не на пустом месте. Данный подход — прекрасно работает в проекте в котором я участвую. На мой взгляд, эти две «вещи» прекрасно совмещаются и позволяют создавать «легковесные требования с упором на цепочку создания ценности, без намека на реализацию» — только бизнес ценность. Легковесность требований — позволяет разработчику (к которому приходит требование), не тратить много усилий на то чтобы удержать в своей голове «функциональную спецификацию», позволяет всегда концентрироваться на ключевых вещах: для кого — что необходимо — зачем.
P.S. Более глубоко — его помещает в контекст аналитик — разъясняя предметную область (например на этапе планирования итерации).

Вы бы могли попробовать в следующей статье предложить использование метода fishbone diagrams или деревьев текущей реальности или еще каких либо методов для достижения похожих целей (вместо техники «5 Whys»), я с удовольствием почитаю ее.

Вторичная цель статьи — это получить несколько конструктивных комментариев к статье, чтобы получить информацию о других взглядах и подходах. В достижении этой цели, вы прекрасно мне помогли, за что я вам и благодарен. Собираюсь изучить данные вами ссылки: Root-Conflict Analysis Plus, Value Chain, Value Shop и Value Network.

Что же касается, рассуждений на тему «…Но ваши идеи изменить метод приводят к его усложнению, следовательно, вы ухудшаете главное преимущество метода 5Why — его простоту (я бы даже сказал, святую простоту)…«.
У меня нет никаких оснований полагать что я хоть сколько усложняю технику, так как она все так же легка в восприятии (но хочу заметить, сложна в применении — так как поиск качественного ответа это достаточно сложная задача — те кто на практике применял этот метод, поймут о чем я говорю). Хоть я и ответил на эти строки, считаю — что рассуждения о «простоте», достаточно неблагодарное занятие — простота для разных людей — разная!

Резюме: … в чем смысл моей идеи? …
Смысл моей идеи — совместить формат легковесного требования User Story и технику 5 Whys (поданную под другим «углом»), для создания легковесных требований с более детальной проработкой «цепочки создания ценности», которое в свою очередь будет вести разработчика на этапе проектирования и реализации, и позволит принять более оптимальное решения опираясь на «требуемую» ценность для пользователя.

Мне кажется что мои комментарии — уже в два раза больше (по объему) — чем сама статья =)

Привет, Михаил,
я представляю старую школу (old school), и в наше время диаграммы Исикавы назывались диаграммы Ишикавы, а fishbone была известна как fish-back («рыбий хвост»).

Теорию ограничений лучше изучать по книге Уильяма Детмера «Теория ограничений Голдратта», в которой расписаны различные аналитические техники. В статье в Wiki эти техники даже не упоминаются.

С моим подходом вы можете ознакомиться здесь: http://analyst.by/tag/triz

Чуть позже я подробнее отвечу вам по-поводу моего видения содержания User Story.

Как раз из комментариев (не из статьи) мы узнали, что подход опробован и действительно работает. Это уже говорит о том, что обсуждение не зря велось. В целом было интересно узнать о таком варианте совмещения техник. Да и Вы, как оказалось, нашли для себя новые области для изучения благодаря Андрею.

Михаил, спасибо за статью. Будем ждать следующую.

Применял пользовательские истории на 7 проектах: на 5 в качестве скрам-мастера, обучая менеджеров обязанностям PO, и на 2, являясь непосредственно владельцем продукта.
Прикинул, как может мне помочь метод 5 почему при работе с ними, и понял, что никак.
Во-первых, если Вы читали «User Stories Applied» Майка Кона (или Рона Джефриса, на которого тот ссылается), то, наверняка, помните, что сама концепция историй строится на 3 принципах: Card, Conversation, Confirmation. Занести историю на карточку (Card) можно и на первой встрече с заказчиком, если он действительно знает, чего хочет. Я остался очень доволен предметностью бесед, после того, как стал с самого начала встречи писать эпики (epics), доводя их в итоге до историй, на обратной стороне которых делал важные пометки.
Во-вторых, обсуждения с командой разработки (Conversation) могут проходить дальше как с участием самого заказчика, так и лично со мной. Во втором случае у меня на руках уже есть бизнес-модель (business model) и карта эффектов (impact map). Их вполне достаточно для объяснения всех действительно важных причинно-следственных связей.
В-третьих, на основании всех бесед я пишу главу Руководства пользователя и согласовываю её с заказчиком. Это лучший тестовый сценарий, какой можно только себе представить для приёмочного тестирования (Confirmation).
Ни на одном из перечисленных этапов метод 5 почему не может играть ключевой роли, а может быть использован лишь в качестве вспомогательного инструмента.
Не могли бы Вы привести конкретные примеры использования описанной Вами техники? Возможно, тогда мне станет понятнее, где и как именно её можно применить.

Добрый день, Вадим!
Извиняюсь за «перекидывание стрелок», могу ли я попросить написать парочку User Stories из вашего последнего проекта, мне просто хочется посмотреть хоть раз на «профессионально написанные истории»? (Параллельно — обещаю ответить на ваши вопросы)

Соответственно, истории (формируются в effectcup.сom автоматически):

3.1 Как Начальник Инспекции труда РМ, я хочу просмотреть экранные отчёты, чтобы ознакомиться со статистическими данными Инспекции.
3.2 Как Начальник Инспекции труда РМ, я хочу вывести печатные отчёты, чтобы ознакомиться со статистическими данными Инспекции.
3.3 Как Начальник Инспекции труда РМ, я хочу задать основные направления деятельности, чтобы составить Программу деятельности Инспекции на год.
3.4 Как Начальник Инспекции труда РМ, я хочу выдать территориальному инспектору Распоряжение о расследовании, чтобы инициировать расследование несчастного случая.
3.5 Как Глава территориальной инспекции, я хочу просмотреть экранные отчёты, чтобы ознакомиться со статистическими данными своего отделения.
3.6 Как Глава территориальной инспекции, я хочу вывести печатные отчёты, чтобы ознакомиться со статистическими данными своего отделения.
3.7 Как Глава территориальной инспекции, я хочу составить список предприятий для контроля, чтобы составить Квартальный план отделения.
3.8 Как Глава территориальной инспекции, я хочу выбрать предприятия для контроля из Квартального плана, чтобы составить Месячный план отделения.
3.9 Как Глава территориальной инспекции, я хочу выдать территориальному инспектору Распоряжение на проверку, чтобы инициировать проверку предприятия.
3.10 Как Территориальный инспектор, я хочу сформировать Акт проверки, чтобы провести проверку предприятия.
3.11 Как Территориальный инспектор, я хочу сформировать Акт(ы) о правонарушении в случае обнаружения нарушений, чтобы провести проверку предприятия.
3.12 Как Территориальный инспектор, я хочу сформировать Предписание о приостановке деятельности в случае нарушений, представляющих угрозу для жизни и здоровья сотрудников, чтобы провести проверку предприятия.
3.13 Как Территориальный инспектор, я хочу сформировать Дело о расследовании, чтобы провести расследование несчастного случая на производстве.
3.14 Как Территориальный инспектор, я хочу сформировать Акт несчастного случая, чтобы провести расследование несчастного случая на производстве.

На карточки для скрам-доски (висит сейчас перед глазами 🙂 в качестве манифестаций историй нанесены более краткие формулировки: Программа деятельности (со следующими значениями: проект — IM (Inspectia muncii (рум.) — Инспекция труда), важность — 30, сложность — 14, исполнители — K, N, V (первые буквы имени разработчиков); значения разнесены по углам карточки в специальных выемках), Квартальный план (IM, 27, 10, K) и т. д.

Обозначение проекта нужно для того, чтобы различать карточки между собой — сейчас на доске есть истории сразу по 3-м проектам. С недавнего времени для различения стали использовать также цвет карточки (просто я нашёл в биротике на 3-м этаже разноцветные бумажки ))

Важность и сложность, думаю, комментировать не имеет смысла, это классика (у Книберга описано).

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

Спринт начали в этот понедельник и три истории уже близки к завершению, чему я донельзя рад )

Единственный существенный недостаток, который я сейчас вижу, это то, что мы ещё не пришли с руководством Инспекции к измеримым метрикам бизнес-цели. Я пока предварительно указал, что совокупное число нарушений и несчастных случаев должно два года подряд снижаться, хотя, конечно, это не очень хорошая метрика, ввиду того, что она зависит от множества факторов вне рамок проекта. Зато это отличная цель для самой Инспекции ))

В общем, буду рад конструктивной критике 😉

Ой, простите, не ту версию карты дал. Вот последняя: https://dl.dropbox.com/u/3442793/Google%20Drive/Proj/IM/121016-IM-Effectmap-2.0.png 🙂

Добрый вечер, Вадим!

Изучил данный вами материал, «честно» постарался осознать предметную область, но для «достаточного» понимания мне не хватило данных. Не смотря на это я взял на себя смелость «поиграться» над одним из ваших требований, результаты ниже:

Попробую поэксперементировать прямо в рамках вашего проекта, буду предполагать т.к. не всю необходиму информацию, для построения User Stories с применением 5Whys, удалось “выудить” из ваших данных.

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

То для территориального инспектора, одну из User Story я бы сформулировал следующим образом:

Как Территориальный Инспектор, я хочу иметь возможность просмотреть список предприятий на которых мне поручено провести проверку или список заявок на проведение проверок

чтобы выбрать предприятие/заявку на котором я на данный момент провожу проверку

чтобы для выбранного предприятия/заявки составить “Акт проверки”
чтобы для выбранного предприятия/заявки составить “Акт о правонарушении”, если обнаружено

чтобы на основании этого акта соствить “Предписание о приостановке деятельности”, если правонарушение относится к разряду “злостных”

чтобы на основании предписания, деятельность предприятия было приостановлено до разбирательства и устранения причин правонарушения

чтобы “Акт о правонарушении” был учтен при расчете статистики правонарушений по территории за которое отвечает территориальное отделение

чтобы на основании этой статистики Галва Территориального Отделения мог судить о сокращении числа правонарушений по территории

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

Если ход моих мыслей — покажется интересен, я готов потратить еще время и предложить еще несколько вариантов, но для этого потребуется дополнительная информация. Если честно — мне это интересно!

ой, все мое форматирование комментария куда-то пропало… Очень жаль — без форматирования будет трудно читать…

User story что это

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

User story

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

Главное действующее лицо User story – это некий персонаж, который будет совершать какие-либо действия с нашим тестируемым продуктом с учетом его потребностей. Персонаж сопровождается описанием проблем, которые он может (и хочет) решить с помощью нашего продукта. Потребность представляет собой тезис в 1-2 предложения. Для одного пользователя может быть разработано несколько (например, 4-6) User Story.

Как определить персонажей и их потребности?

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

По клику на картинку откроется полная версия.

По клику на картинку откроется полная версия.
Для этого нам потребуется помощь заказчика и плотное взаимодействие по вопросу создания персонажей. К сожалению, большинство заказчиков, отвечая на вопрос «кто ваша целевая аудитория?», дают ответ: «Все люди». Это неверно. Например, уборщица страховой компании Вера Ивановна 63-х лет и охранник Володя 37 лет не имеют никакого отношения к ПО, являясь при этом сотрудниками.

Как же выявить нужных нам персонажей и определить их потребности? Это довольно просто: оцениваем количество модулей продукта и их смысловую нагрузку, а затем задаем заказчику правильные вопросы. В той же страховой компании функциональные модули «Контрагенты», «Агентские договоры», «Договоры страхования» и «Вознаграждение» говорят нам о том, что в системе может быть создан страховой агент, для которого будут заведены условия вознаграждения, а при наличии договоров страхования – произведен расчет комиссионного вознаграждения.

Необходимо расспросить заказчика об агентах: сидят ли они в офисе или работают «в полях», занимаются продажами и сопровождением ОСАГО и КАСКО или обзванивают «холодный круг» (клиентов из числа тех, с кем ранее никогда не контактировали)? После фиксации и анализа ответов можно приступать к проектированию персонажей.

Пользовательский сценарий

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

В тестируемом нами ПО для страховой компании существует 15 функциональных модулей. В модуле «Контрагенты» хранится информация обо всех действующих агентах и контрагентах, которые сотрудничают со «Страховой компанией». В модуле «Агентские договоры» производится учет условий вознаграждения для агентов. Модуль «Договоры страхования» систематизирует договоры страхования по различным видам: авто, несчастный случай, имущество физических и юридических лиц и др.

Наш персонаж – страховой агент Мария. Мария сделала неплохую карьеру, сотрудничая со «Страховой компанией» на протяжении трех лет, она имеет несколько десятков агентских договоров по разным видам с индивидуальными условиями вознаграждения. Последний ее клиент, которому она предоставила скидку за счет своего комиссионного вознаграждения при оформлении полиса КАСКО, недавно стал ее мужем. После регистрации брака Мария сменила фамилию. Теперь Марии необходимо изменить фамилию в личной карточке «Страховой компании».

По клику на картинку откроется полная версия.
Мы смоделировали одну из возможных жизненных ситуаций. Что делать дальше? Приступать к тестированию? Пожалуй, рановато. На этом этапе логичнее будет разработать Use case (варианты использования) и при необходимости составить на их основе тест-кейсы. Более подробно о Use case вы можете почитать в книге А.Коберна «Современные методы описания функциональных требований к системам». В этом труде содержится много полезного материала, но в рамках функционального тестирования нам достаточно знать основной принцип применения этой техники – выделение обобщенных последовательностей действий лиц и ответов системы на эти действия. Ответы, в свою очередь, составляются на основе анализа действующих лиц и их конечных целей в различных условиях (с учетом соглашения о поведении рассматриваемой системы).

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

Почему User story удобны при тестировании страховых продуктов?

Согласитесь, к тестированию можно было бы подойти иначе. Не используя User story (особенно этап создания персонажей) и Use case, мы могли проверить функциональность модуля «Контрагенты» в плане создания, сохранения и редактирования данных, а потом завести баги в случае неверной работы какой-то части модуля. Однако, этого оказалось бы совершенно недостаточно, так как все модули тестируемого страхового ПО взаимосвязаны между собой. Изменения, внесенные в один модуль, должны быть обработаны другим модулем: так, исправления в карточке контрагента влекут за собой корректировку данных в агентских договорах, договорах страхования и в агентском портале.

Заключение

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

Таким образом, мы можем однозначно сказать: применение в тандеме техник User story и Use case оправдано в силу того, что они дополняют друг друга и позволяют не только качественно протестировать продукт, но и получить, дополнить и проверить требования в случае их наличия.

Основы пользовательских историй. Часть 3: Инвестируйте в качественные пользовательские истории

Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.

Инвестируйте в качественные пользовательские истории

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

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

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

Независимость

Независимость означает, что стори может быть разработана, оттестирована и возможно даже доставлена сама по себе. В силу этого она может нести независимую ценность.

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

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

1) Как администратор я могу установить правила безопасности пользовательских паролей так, что пользователи будут обязаны создавать и поддерживать безопасные пароли, поддерживая безопасность системы.
2) Как пользователь я должен следовать правилам безопасности паролей, установленным администратором, чтобы поддерживать безопасность моей учетной записи.

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

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

1′) Как администратор я могу установить период истечения действия пароля, таким образом пользователи будут обязаны периодически менять пароли.
2′) Как администратор я могу установить характеристики сложности пароля, так что пользователи будут обязаны создавать пароли, которые сложно подобрать.

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

Обсуджаемость

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

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

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

Польза

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

Типичный вызов, с которым сталкиваются команды – научиться писать небольшие, инкрементальные пользовательские истории, подходящие для эффективной доставки ценности. Традиционные подходы запечатлели в нас алгоритм функциональной разбивки требований на технические компоненты. Этот подход «технического наслоения» при разработке систем замедляет доставку до тех пор, пока все слои не будут соединены воедино в результате многочисленных итераций. Вейк 9 (Wake) предлагает свое видение скорее вертикального, чем технического (горизонтального), наслоения:

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

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

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

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

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

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

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

Произвести рефакторинг системы логирования ошибок.

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

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

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

Эстимируемость

Хорошая пользовательская история эстимируема. Несмотря на то, что в бэклоге может лежать стори любого размера, для того, чтобы ее можно было реализовать и оттестировать в рамках одной итерации, команда должна быть способна предоставить приблизительную оценку ее сложности и объема работы, необходимой для ее завершения. Минимальная инвестиция в эстимирование стори – это определение того, войдет ли она в рамки одной итерации. Дополнительная точность в эстимировании увеличит предсказуемость команды.

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

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

Компактность

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

Увеличение пропускной способности

Как известно из теории массового обслуживания, более компактные пакеты проходят сквозь систему быстрее. Это один из ключевых принципов бережливого производства и отражен в законе Литтла (Little):

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

Более того, когда система загружена полностью, она может стать нестабильной и проблема может нагромождаться. В сильно перегруженных системах большие пакеты двигаются сквозь систему непропорционально медленно, так как пропускная способность падает. (Представьте себе шоссе в час пик. У мотоцикла шансов нормально передвигаться значительно больше, чем у легковых автомобилей и грузовиков – значительно легче маневрировать компактными объектами при движении в нагруженной системе.) Поскольку команды разработчиков обычно заняты почти на полную нагрузку, а то и выше (80-120%), они также попадают в «час пик».

Рисунок 1. У больших пакетов больше продолжительность цикла и выше вариация.

Более компактные пользовательские истории проходят сквозь процесс разработки быстрее не только из-за их пропорционального объема, но и из-за меньшей сложности, а сложность нелинейно зависит от объема. Это лучше всего наблюдается в тестировании, где разветвленность системы тестов, необходимых для валидации функциональности, растет экспоненциально по отношению к объему самой функциональности. Это соответствует рекомендации по разработке чистого кода, а именно, Роберт Мартин [Martin 2009] предлагает следующие правила для функций системы:

О соотношении объема и независимости

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

Тестируемость

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

Чтобы удостовериться в том, что стори не попадут в итерацию, если они не способны из нее выбраться (то есть быть успешно оттестированными), много гибких команд на сегодняшний день применяет подход: «сначала тесты». Это берет начало в XP-сообществах, использующих Разработку через тестирование (TDD) – практику написания автоматизированных юнит тестов перед написанием кода, который должен этим тестам удовлетворять.

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

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

Литература

Что за User Story?

Собственно, для этого и предназначены «Пользовательские истории». Они должны быть описанием требований и коммерческой ценности от их реализации, а также набором критериев, по которым мы все будем оценивать конечный результат. Это более строгое определение, чем в других гибких (Agile) методологиях, где это в разных случаях определяется как «договоренность по понятиям» (promise of a conversation) или «описание функции». Пользовательская история в нотации BDD может с лёгкостью описывать нефункциональные требования, при этом объём работ по такому описанию может быть зафиксирован, осмечен и согласован.

Структура пользовательской истории

Английский вариант Локализованный вариант Title (one line describing the story)

As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context]

And [some more context].

When [event]

Then [outcome]

And [another outcome].

Заголовок(описание истории в одну строку)

Я как [роль]

Хочу [функционал]

Для того чтобы [выгода]

Критерии приёмки: (описываются сценариями)

Сценарий 1: Заголовок

Дано [контекст]

И [ещё немного контекста].

Когда [событие]

Тогда [результат]

И [ещё один результат].

Рассказывая пользовательскую историю

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

Критерии качества пользовательской истории

Используя пример из статьи «Введение в BDD» давайте посмотрим на требования по реализации извлечения наличных из банкомата.

Английский вариантЛокализованный вариант Story: Account Holder withdraws cash

As an Account Holder

I want to withdraw cash from an ATM

So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds

Given the account balance is \$100

And the card is valid

And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should dispense \$20

And the account balance should be \$80

And the card should be returned

Scenario 2: Account has insufficient funds

Given the account balance is \$10

And the card is valid

And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should not dispense any money

And the ATM should say there are insufficient funds

And the account balance should be \$20

And the card should be returned

Scenario 3: Card has been disabled

Given the card is disabled

When the Account Holder requests \$20

Then the ATM should retain the card

And the ATM should say the card has been retained

Scenario 4: The ATM has insufficient funds

История: Владелец карточки снимает наличку

Я как Владелец карточки

Хочу снять наличку в банкомате

Для того чтобы я мог получить деньги, когда банк закрыт

Сценарий 1: На карточке хватает денег

Дано на карточке лежит 100 долларов

И карточка активна

И в банкомате достаточно денег

Когда когда Владелец карточки запрашивает съём 20 долларов

Тогда банкомат должен выдать 20 долларов

И баланс на карточке должен стать 80 долларов

И карточка должна быть возвращена

Сценарий 2: На карточке НЕ хватает денег

Дано на карточке лежит 10 долларов

И карточка активна

И в банкомате достаточно денег

Когда Владелец карточки запрашивает съём 20 долларов

Тогда банкомат должен НЕ выдать денег

И банкомат должен сообщить о нехватке средств на карте

И баланс должен остаться 10 долларов

И карточка должна быть возвращена

Сценарий 3: Карточка аннулирована

Дано карточка аннулирована

Когда когда Владелец карточки запрашивает съём 20 долларов

Тогда банкомат должен заблокировать карточку

И банкомат должен сообщить об удержании карты

Сценарий 4: В банкомате не хватает налички

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

Заголовок должен описывать действие

Формулировка истории должна включать в себя роль, функцию и выгоду

Становится интереснее, когда вы обнаружите, что реализация заказанного функционала не приводит к получении заявленной выгоды. Обычно это значит, что у вас есть «потерянная история». То есть имеем одну историю, реализующая текущую функцию, но приносящая не ту, но всё таки выгоду (и поэтому всё ещё имеющая право на существование). И также существует другая (скрытая) история, в которой нужно реализовать другой функционал, чтобы получить, заявленную в первой истории выгоду.

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

Заголовок сценария должен фокусироваться на отличиях в ситуациях

Сценарий должен быть описан в терминах: Дано, События, Результаты

Это единственный наиболее мощный поведенческий сдвиг, который я когда-либо видел в командах, практикующих BDD. Просто заставляя людей от бизнеса, аналитиков, тестеров и разработчиков адаптировать свою речь в терминах «дано/когда/тогда», мы видим, как проблема двусмысленности отступает.

В «Дано» должен быть описан полностью весь контекст, но не более того

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

Раздел «событие» должен описывать функцию (feature)

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

Пользовательская история должна вписаться в одну итерацию

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

Видимо лучше будет разбить эту историю на несколько более мелких:

Владелец карты извлекает наличку (допущения: банкомат в порядке и карта активная)
Владелец карты извлекает наличку с аннулированной картой (допущения: банкомат в порядке)
Владелец карты извлекает наличку из глючного банкомата (допущения: карта активная)

Ну и чем это отличается от UseCase-диаграмм?

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

Об agile по-русски: User Stories

О чем эта статья?

Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых – поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.

Эта статья рассказывает о применении «user stories» («пользовательских историй») – одной из практик agile. Далее для краткости я буду называть их просто «историями».

Как структурирован этот материал?

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

Как я познакомился с User Stories

Скажу честно, пока я не прочел книги Майка Кона (3), я не верил в то, что этот подход жизнеспособен. Я читал книги по экстремальному программированию (4), про то, как заказчики высказывают требования в виде коротких фраз и обсуждают их с командой, – но все это было далеко от моего понимания, в прочем, как и другие особенности XP… И мне кажется, я был не одинок.

К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum (5), и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.

User stories: экстремальный подход

Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична, как говорят: «it’s about common sense»

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

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

Почему же обсуждение требований так важно?

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

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

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

Как это работает на практике? Пример написания историй

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

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

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

пользователь – одна из обобщенных пользовательских ролей;

действие – действие, выполняемое пользователем посредством взаимодействия с системой;

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

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

Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше – интереснее.
Вопросы?

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

Пример детализации.

Рассмотрим одну из историй, идентифицированную выше:

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

К истории дописывается этой комментарий. Теперь история выглядит так:

Нужен проверенный email и выбранные пользователем имя и пароль.

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

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

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

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

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

Конечно, порой не так легко и очевидно принять правильное решение о порядке историй, но в этом и состоит мастерство быть заказчиком (это отдельная, неисчерпаемая тема…)
Кроме инструментария ранжирования историй, в руках у заказчика есть и другие мощные средства, позволяющие повысить эффективность своих финансовых вложений. К примеру, одна из описанных на ранней фазе проекта историй в какой-то момент может показаться слишком большой в сравнении с другими, что усложняет понимание её приоритета:

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

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

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

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

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

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

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

Как правильно писать User Stories: руководство для разработчиков

Перевод статьи «Engineering guide to writing correct User Stories».

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

Взгляните на этот пример:

На вид совершенно нормальная user story, правда? Но на самом деле эта маленькая история имеет несколько проблем. И если вы не можете найти в ней как минимум 8 ошибок, вам действительно стоит прочесть эту статью.

Статья делится на три основные части:

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

Обнаружение и исправление проблем

User stories имеют тенденцию упускать некоторые из этих характеристик. Нам нужно это исправить.

Последовательность в терминах

Желания «Получать webhooks о проблемах» и «помещать все текущие задачи в список» как-то связаны между собой? «Проблемы» и «задачи» это одно и то же или все-таки нет? Ведь это могут быть как совершенно разные вещи, так и просто неудачный побор слов. Как нам это определить?

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

Допустим, в нашем случае после консультаций с экспертами мы обнаружили, что «задачи» и «проблемы» это одно и то же. Теперь нам нужно удалить неправильный термин.

Прекрасно. Использование одинаковых слов для одинаковых сущностей делает наши требования более понятными и последовательными.

Желания пользователей и ваши желания это не одно и то же

Когда мы изменили последнюю строку, я обратил внимание, что цель пользователя – «помещать все текущие проблемы в список». Зачем бедный пользователь хочет составлять списки проблем? В чем смысл этих действий? Никакой пользователь ничего подобного не хочет. Это просто некорректное требование.

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

Как понять, чего хочет пользователь? Нужно проконсультироваться на этот счет с реальными пользователями или их представителями. Или, если мы не можем ни у кого спросить, придется строить предположения самостоятельно.

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

Убираем технические детали

Вам когда-нибудь доводилось встречать человека, который хотел бы именно «получать webhooks о проблемах»? Это никому не нужно. В данном случае мы тоже смешиваем разные вещи.

Есть четкое разделение между целями пользователя и техническими способами их достижения. И «получать webhooks о проблемах» это определенно детали реализации. Завтра webhooks могут измениться на WebSockets, всплывающие уведомления и т. п. А цели пользователя при этом останутся прежними.

Видите? Теперь осталась только важная информация, без деталей реализации.

Уточнение ролей

Из контекста довольно понятно, что речь идет о каком-то инструменте, связанном с разработкой. Мы используем Gitlab и issue management. Так что не сложно догадаться, что у нас есть разные категории пользователей: джуниоры, мидлы и сеньоры. Возможно, менеджеры проектов, а также другие люди.

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

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

После обдумывания вариантов мы можем разделить user stories по ролям пользователей. А это позволяет нам более тонко контролировать поставляемый функционалом и то, кому мы этот функционал поставляем.

Расширяем user stories

Делаем user stories проверяемыми

Проблема с приведенной выше user story в том, что она по-прежнему не проверяемая. Как нам проверить, что эта история (на данный момент или все еще) является рабочей для наших пользователей? Мы не можем этого сделать.

У нас нет четкой связи между этой user story и нашими тестами. Было бы прекрасно, если бы можно было писать user stories в качестве тестов…

Погодите, но ведь это возможно! Для этого у нас есть BDD («разработка через поведение») и язык gherkin. Именно для этого BDD и создавалась изначально. Это означает, что для того чтобы чтобы сделать нашу user story проверяемой, мы можем переписать ее в формате gherkin.

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

Обнаружение неполноты

Когда мы привыкли писать наши user stories на gherkin, мы начали писать сценарии для наших user stories. И мы обнаружили, что для каждой user story может быть несколько сценариев.

Двайте рассмотрим первый написанный нами сценарий: «получен новый валидный webhook о проблеме». Погодите, но что происходит, когда мы получаем невалидный webhook? Должны мы сохранять эту проблему или нет? Может, кроме сохранения проблемы нужно сделать что-то дополнительно?

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

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

Теперь мы можем добавить еще два сценария, чтобы сделать нашу user story полной.

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

Упорядочиваем user stories по степени важности

Сейчас непонятно, насколько важно для архитекторов «просматривать и отслеживать прогресс по проблемам». Это более важно, чем другие наши user stories? Поскольку это кажется довольно сложным, может, вместо этого нам следует заняться чем-то более простым и вместе с тем более важным?

Расстановка приоритетов важна для каждого продукта, и игнорировать ее нельзя. Даже если user stories это единственный наш способ записи требований. Существуют разные методы для расстановки приоритетов в требованиях, но мы рекомендуем придерживаться метода MoSCoW. В основе этого простого метода лежат четыре главных категории: must, should, could и won’t. Подразумевается, что у нас в проектной документации будет отдельная таблица приоритетов всех пользовательских историй.

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

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

Итак, теперь мы можем изменить название нашей user story, чтобы обозначить приоритет:

Можно даже поставить гиперссылку на таблицу с приоритетами требований в файле с user story.

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

Связывание всего воедино

Если не уделять этому делу достаточно внимания, вы вскоре утонете в перепутанных user stories, тестах, исходном коде и документации. По мере роста вашего проекта станет просто невозможно сказать, какие части приложения за какие use-cases бизнеса отвечают. Чтобы разобраться с этой проблемой, нам нужно связать все вместе: требования, код, тесты и документацию. Наша цель – получить примерно следующее:

Для иллюстрации этого принципа я использую Python.

Я могу определить use-cases как набор уникальных высокоуровневых действий, которые может осуществлять ваше приложение (это очень похоже на точку зрения Clean Architecture).

Обычно я определяю пакет под названием usecases и собираю в нем все use-cases, чтобы было легко их просматривать одновременно. Каждый файл содержит простой класс (или функцию), выглядит это так:

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

Этот класс также можно использовать для тестирования нашей user story. Таким образом мы свяжем требования, тесты и собственно логику, реализующую эту user story.

Заключение

Это руководство поможет вам писать лучшие user stories, фокусироваться на нуждах пользователей, поддерживать чистоту кода и максимально использовать один и тот же код для различных (но сходных) целей.

Job Stories для проектирования интерфейсов

Моделирование целевой аудитории (персонажей) и написание «пользовательских историй» (user story) были эффективными, когда клиенты и разработчики продуктов находились далеко друг от друга. Теперь все по-другому. В этом посте говорится о том, как одна команда разработчиков применила метод Job Stories для создания страницы профиля пользователя.

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

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

Подобный подход, фиксирующийся на причинах поведения, проблемах пользователей и их мотивации, является сутью метода, под названием Jobs To Be Done (концепция «работы», которую «выполняет» продукт), а один из эффективных способов применить его — использование метода Job Stories при разработке сайта, пользовательского интерфейса и опыта взаимодействия.

Проблема моделирования персонажей

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

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

Заголовок: «Почему Питер купил «Сникерс?»;

столбик слева: «Чтобы утолить голод»;

столбик справа: «Ему 35 лет, у него диплом маркетолога, он любит арахис, шоколад, нугу и карамель, он любит батончики «Сникерс» и съедает по одному каждый день. Он ведет активный образ жизни, у него 2 собаки. Он отдыхает в кафе Jack in the box, но покупает еду в Taco Bell. Он вывихнул палец на ноге»

Проблема метода user stories

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

Что такое Job Story

Впервые этот термин был упомянут Полом Адамсом (Paul Adams) и раскрыт более подробно здесь. Метод Job Stories — это иной способ работы с функционалом продукта, пользовательским интерфейсом и опытом взаимодействия. Но как команде разработчиков применить его в своей работе?

Вот один из подходов:

Разработка страницы профиля

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

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

Это профиль продавца автомобилей.

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

Для чего у нашего приложения должная быть страница профиля? Почему она должна быть в этом месте или где-то еще? Какую информацию она должна показывать? Какие обстоятельства она учитывает и какую задачу выполняет?

Чтобы решить эти вопросы, функционал был скорректирован с использованием метода Job Stories.

Примечание: Для краткости в данной статье в основном будет рассматриваться только одна «история» для страницы профиля. На деле же были подготовлены несколько Job Stories.

1. Начните с задачи более высокого уровня

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

2. Определите второстепенные задачи

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

3. Проанализируйте процесс

(то, как пользователи решают рассматриваемую проблему в данное время – какую работу они проделывают сейчас)

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

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

4. Сформулируйте одну или несколько «историй»

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

Когда продавец и его клиент взаимодействуют друг с другом посредством данного приложения…

5. Разработайте решение

(обычно это какое-либо изменение функционала или интерфейса, которое учитывает проблемы, отраженные в «истории»)

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

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

Надпись над фотографией («Ваш менеджер по продажам»), фото профиля и имя продавца: все это напоминает клиенту, кто такой Джои (Филгуд) и уменьшает беспокойство по поводу того, что он не находится рядом с продавцом.

Должность продавца: главный менеджер по продажам, количество проданных машин (500) и комментарий («8 лет в компании Грэйт Сэйлс»). Это подтверждает, что Джои компетентен, и другие люди ему доверяют.

Номер телефона, почтовый адрес и кнопка «Задать вопрос» — с Джои легко связаться, и это уменьшает беспокойство клиента по поводу того, что он не сможет самостоятельно заполнить форму.

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

Проектирование приложений с учетом реальных условий их использования

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

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

Использование Job Stories для создания функционала, пользовательского интерфейса и опыта взаимодействия является одним из способов достичь этого. О других решениях в данной сфере и не только – в нашем переводе книги UX-команды MailChimp.

Шаблон сценария (user story) — популярный подход к описанию задач в SCRUM/Agile

Одна из ключевых проблем в разработке продуктов — взаимопониманием стейкхолдеров и команды, а также всех участников внутри команды. Один из классных подходов с решением проблемы — формат user story.

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

Сценарии (пользовательские истории, user story) — это быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель сценариев состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира.

Определение из Вики

Пользовательские истории (англ. User Story, вариант перевода Сценарии) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приёмочными испытаниямиruen). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — пишутся либо одобряются ролью владельца продукта (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.

Формат

Примеры User Story

Декомпозиция User Story

Чтобы реализовать задачу типа US, бывает нужно ее декомпозировать.

Можно прописать и структурировать аспекты по задаче. Отлично подходит практика ВИСИ.

Иногда есть смысл сделать ToDo-список по реализации.

А во многих трекерах US можно разбить на подзадачи и отслеживать прогресс выполнения.

User Stories

«Разработка ПО — это игра изобретательности и кооперации»

Сразу хочу предупредить, что эта история об историях весьма объёмна. Так сказать, лонгрид из личного опыта.

Скажу честно, пока я не прочел книги Майка Кона, я не верил в то, что этот подход жизнеспособен.

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

Мне кажется, я был не одинок.

К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum, и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.

USER STORIES: ЭКСТРЕМАЛЬНЫЙ ПОДХОД

Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична. Как говорят: «It’s about common sense».

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

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

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

Почему же обсуждение требований так важно?

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

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

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

КАК ЭТО РАБОТАЕТ НА ПРАКТИКЕ? ПРИМЕР НАПИСАНИЯ ИСТОРИЙ

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

Это короткое предложение — ничто иное как видение (vision) системы. Его вполне достаточно для того, чтобы начать описывать истории. Но сначала давайте идентифицируем группы пользователей, истории будут рассказаны от их имени. Знание о будущих пользователях поможет нам сфокусироваться на нуждах каждого из них, не упустив важные моменты в требованиях к системе. Итак, разными аспектами системы будут пользоваться такие обобщенные пользовательские роли:

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

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

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

Во время обсуждения первой истории заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» — группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.

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

Обсуждая концепцию учетных записей, рождаются также следующие истории:

Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше — интереснее.

ВОПРОСЫ?

К этому моменту, я надеюсь, у вас появилось много интригующих вопросов. Вохможно даже,, у вас их стало больше, чем до начала чтения этой статьи.

Я попробую вкратце разъяснить как же всё-таки это все может работать.

КУДА ДЕЛИСЬ ДЕТАЛИ?

Первый вопрос, который задаёт человек, который привык работать с более тяжеловесным подходом к требованиями (основанным, к примеру, на подходе Software Requirements Specifications из RUP), — это: «Куда подевались детали?».

Это вопрос затрагивает ключевой аспект использования историй. Попробую коротко объяснить.

Конечно, детали есть, и их никто не отменял — как без понимания деталей программист может написать адекватный код, а тестировщик его принять? Детали необходимы. Но использование историй смещает суть и время выработки деталей.

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

ПРИМЕР ДЕТАЛИЗАЦИИ.

Рассмотрим одну из историй, идентифицированную выше:

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

К истории дописывается этой комментарий. Теперь история выглядит так:

Нужен проверенный email и выбранные пользователем имя и пароль.

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

Тест 1: Нужен проверенный email и выбранные пользователем имя и пароль.

Тест 2: Пользователь не может ввести имя меньше 3 и больше 20 символов.

Тест 3: Пользователь должен иметь уникальное имя в системе.

Тест 4: После регистрации пользователь должен получить имейл для активизации своей учетной записи.

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

Тест 6: При успешном входе система приветствует пользователя текстом «Добро пожаловать, ».

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

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

МОЩНЫЕ ИНСТРУМЕНТЫ РАБОТЫ С ИСТОРИЯМИ: УПОРЯДОЧИВАНИЕ, РАЗБИЕНИЕ И ГРУППИРОВКА

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

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

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

Вот пример, как могли бы быть отсортированы истории вышеописанного проекта (это всего лишь один из вариантов, конечно, есть и другие):

Как вы видете, истории выстроены в порядке, который, во-первых, логичен с точки зрения заказчика и команды, а, во-вторых, ценность историй уменьшается сверху вниз. Таким образом, если, к примеру, на половине проекта наступает нехватка ресурсов (скажем, после реализации истории для администратора системы), заказчики смогут получить выгоду от продукта, так как наиболее важные истории уже будут реализованы. Это ни что иное как минимизация рисков от вложений.

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

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

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

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

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

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

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

Как вы до сих пор справлялись с подобными задачами?

ДИНАМИКА ЗНАНИЙ

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

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

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

ЧТО ДАЛЬШЕ?

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

Что же делать с нашим беклогом? Давайте его погрумим.

Разбиение пользовательских историй – метод гамбургера

Предлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: «Splitting User Stories: The Hamburger Method» — сделал его, в первую очередь, для себя.

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

Решение: Метод гамбургера

В течение последних нескольких месяцев я разработал новую технику разбиения пользовательских историй, бессовестно украв пересмотрев и использовав метод составления пользовательских историй Джеффа Паттона и идеи, описанные Крейгом Ларманом и Басом Водде в Практиках масштабирования Lean и Agile-разработки. Я думаю, что эта техника особенно хорошо работает в ситуациях, когда команда не может разрушить традицию технического разделения задач на истории. У неё есть визуальный игровой аспект, как в Инновационных играх, и её просто запомнить. Я называю её Юзер Стори-Гамбургер.

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

ШАГ 1: Определение задач — слоёв гамбургера

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

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

ШАГ 2: Определение различных способов реализации задач

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

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

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

ШАГ 3: Объединение результатов

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

ШАГ 4: Обрежьте гамбургер

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

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

ШАГ 5: Сделайте первый укус

Теперь, когда гамбургер готов, решите, насколько большой кусок вы готовы откусить. Определитесь с минимально приемлемым уровнем качества для каждого слоя гамбургера. Например, будем считать ручную рассылку неприемлемой ввиду низкой эффективности, но ежемесячная отправка может быть вполне приемлемой. Если вариант с меньшим уровнем качества является более-менее близким к опции высшего качества по сложности реализации, тогда вам стоит откусить сразу кусок побольше. Например, реализация авторассылки неперсонализированных писем с ручной отпиской не будет гораздо более сложной, чем интеграция с MailChimp. Обратный пример – обновление клиентской активности в реальном времени может оказаться более трудоёмким, чем медленный запрос из базы по требованию. А для некоторых этапов, например, для задачи по удалению некорректных адресов, отсутствие реализации уже может быть минимальным требованием.

ШАГ 6: Откусите еще раз… и продолжайте

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

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

Как правильно разделить разработку веб-проекта на юзер-стори?

Пытаемся в команде внедрить гибкую методологию разработки веб-проектов. До этого работали по классическому waterfall (Каскадная модель), но проекты тянуться в сроках.

В данный момент пришла задача на перенос крупного проекта с одной платформы(asp.net) на другую(php). И у меня стал вопрос, каким образом правильно подойти к поставлению юзер-стори проекта.

Коллеги, прошу вашей помощи 🙂

Принцип работы по методологии сложился полностью, затык именно в юзер-стори(хотя может я и ошибаюсь)

В своё время вот эта книга для меня послужила (пару лет назад) неплохим введением в тему, рекомендую. Думаю в ней вы найдёте ответы на большинство вопросов.

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

В общем это я своими словами описал принцип «Заказчик всегда рядом».

Ещё один из основополагающих принципов ( в той же книге ему не мало внимания уделено, насколько я помню): интерфейсные решения должны приниматься как можно позже. Темы вёрстки и интерфейса и должна быть не раскрыта как можно дольше. Идите от функциональных требования к системе, а не от прототипов интерфейса! Я лично вообще считаю проектирование от гуя большим злом и признаком не высокой компетентности бизнес-аналитика, если проект посложнее сайта визитки — стоит смотреть в сторону DDD. У Фаулера, кажется, на эту же тему есть формулировка о хорошем программном дизайне (воспроизвожу по памяти, могу ошибаться как в точности, так и в источнике):

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

Вам будет интересно: Как показать себя в «Скайпе» при помощи вебкамеры

Пояснение

Создания

Вам будет интересно: Программа для разгона микропроцессоров AMD OverDrive. Как пользоваться этой утилитой, порядок настройки

С Extreme Programming (XP) пользовательские истории стали частью игры планирования.

Требования

Как составлять хорошие User Story? В 2001 году Рон Джеффрис предложил формулу «Три C» для создания пользовательских историй:

В некоторых командах менеджер по продукту (или владелец продукта в Scrum) несет основную ответственность за формулирование пользовательских историй и организацию их в портфель продуктов. В других командах любой может написать историю пользователя. Примеры User Story написаны или для пользователей, для или клиентов, чтобы влиять на функциональность разрабатываемой системы. Пользовательские истории могут быть разработаны путем обсуждения с заинтересованными сторонами, на основе персон или просто составлены. Так написано в официальном руководстве How to do User Story mapping.

Вам будет интересно: Серия графических адаптеров AMD Radeon HD 7000 Series. Спецификации и настройка

Методы

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

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

Спорный статус

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

Ограничения пользовательских историй включают в себя:

Коммуникативное значение

Вам будет интересно: Программа для разгона процессора AMD: название, настройки и нюансы работы

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

Отсутствие нефункциональных требований

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

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

Метки

Эпики

Множество эпосов или историй, сгруппированных по иерархическому принципу, в основном известны из Jira.

User Story map: описание

Карта истории представляет собой графическую двумерную визуализацию отставания продукта. В верхней части карты находятся заголовки, под которыми сгруппированы истории, обычно называемые «эпосами» (большие грубые пользовательские истории), «темами» (сборниками связанных пользовательских историй) или «действиями». Они определяются путем ориентации на рабочий процесс пользователя или «в порядке, в котором вы бы объяснили поведение системы». Вертикально, ниже эпопей, фактические примеры User Story map расположены и упорядочены по приоритету. Первый горизонтальный ряд представляет собой «ходячий скелет» и ниже, что представляет растущую изощренность.

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

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

Шаблон

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

Преимущества

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

Вам будет интересно: Как пользоваться Paint: возможности программы

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

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

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

Условия удовлетворения

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

В этот пример пользовательской истории можно добавить подробности, добавив следующие условия удовлетворения:

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

Также обратите внимание, что тот, кто пишет историю пользователя, гораздо менее важен, чем тот, кто участвует в ее обсуждении.

Значение для проектов

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

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

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

В то время как отставание по продукту можно рассматривать как замену документа требований традиционного проекта, важно помнить, что письменная часть гибкой пользовательской истории («Как пользователь, я хочу…») является неполной до обсуждения об этой истории происходят. Так написано в американском мануале User Story mapping and how to use it.

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

Job Story + User Story = ❤️

Недавно, на курсе по JTBD студент задал древний, как вселенная, вопрос: “чем отличаются Job Story от User Story?”. Я удивился, потому что вроде бы давно поставил в этом вопросе точку в своей статье. А потом я понял, что забыл ее опубликовать 4 года назад 😳. В общем, вот она.

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

Job Story (как и JTBD Statement ) — это инструменты для описания проблемной ситуации, в которой оказался человек и его стремления к улучшению / прогрессу. Не привязаны к решению. Используются на этапе выбора “проблемы”, которую будет решать продукт или фича. Берем их с собой на брейншторм, чтобы придумывать идеи фичей / продуктов или принимать решение о направлениях развития.

User Story — это способ коротко описать необходимый функционал для определенной роли пользователя в системе. Они создаются для того, чтобы объяснить программистам и дизайнерам, какую фичу / функцию в продукте нужно создать. Придумываем фичу, пишем про нее User Story и передаем исполнителям в качестве “микро ТЗ”.

Если использовать Job Story и User Story вместе, то это выглядит так:

Как работает на примере:

1) Мы исследовали пользователей боксерских секций и нашли потребность, которую некоторые из них пытаются решить с помощью бокса.

2) Описываем в формате Job Story:

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

4) Чтобы эту идею реализовать, мы пишем задачи сотрудникам боксерской секции (в цифровых продуктах, обычно это PM, дизайнеры, программисты). Их можно оформить в формате User Story:

5) Команда приоритезирует User Stories и отправляется реализовывать требования к продукту, которые в них описаны ☺️

Как видите, можно закрыть этот вопрос раз и навсегда и жить дружно.

User story что это

Что пишут в блогах

Лет 5 назад наваял на коленке для рассказа разработчикам про тестирование в команде без тестировщиков.

С радостью сообщаю о старте нового ютуб-канала «Багаж тестировщика»

Сейчас на канале 2 видео:

Завершаем тему Лидерских навыков.

Ух. Это случилось.

Теперь я — Ольга Назина, генеральный директор ООО «Тестбейз»!

Полезняшки от автора тренажера — https://qahacking.ru/

30 сентября — 1 октября в Ереване пройдет конференция SQA Days EA.

Что пишут в блогах (EN)

Spacing in Galleries

Разделы портала

Онлайн-тренинги

Автор: Нина Агеева, тест-менеджер компании «Лаборатория качества»

При написании статьи были использованы материалы Владимира Беленя, подготовленные в рамках внутреннего обучающего семинара проектной команды Лаборатории качества «User story & friends».

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

User story

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

Главное действующее лицо User story – это некий персонаж, который будет совершать какие-либо действия с нашим тестируемым продуктом с учетом его потребностей. Персонаж сопровождается описанием проблем, которые он может (и хочет) решить с помощью нашего продукта. Потребность представляет собой тезис в 1-2 предложения. Для одного пользователя может быть разработано несколько (например, 4-6) User Story.

Как определить персонажей и их потребности?

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

Для этого нам потребуется помощь заказчика и плотное взаимодействие по вопросу создания персонажей. К сожалению, большинство заказчиков, отвечая на вопрос «кто ваша целевая аудитория?», дают ответ: «Все люди». Это неверно. Например, уборщица страховой компании Вера Ивановна 63-х лет и охранник Володя 37 лет не имеют никакого отношения к ПО, являясь при этом сотрудниками.

Как же выявить нужных нам персонажей и определить их потребности? Это довольно просто: оцениваем количество модулей продукта и их смысловую нагрузку, а затем задаем заказчику правильные вопросы. В той же страховой компании функциональные модули «Контрагенты», «Агентские договоры», «Договоры страхования» и «Вознаграждение» говорят нам о том, что в системе может быть создан страховой агент, для которого будут заведены условия вознаграждения, а при наличии договоров страхования – произведен расчет комиссионного вознаграждения.

Необходимо расспросить заказчика об агентах: сидят ли они в офисе или работают «в полях», занимаются продажами и сопровождением ОСАГО и КАСКО или обзванивают «холодный круг» (клиентов из числа тех, с кем ранее никогда не контактировали)? После фиксации и анализа ответов можно приступать к проектированию персонажей.

Пользовательский сценарий

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

В тестируемом нами ПО для страховой компании существует 15 функциональных модулей. В модуле «Контрагенты» хранится информация обо всех действующих агентах и контрагентах, которые сотрудничают со «Страховой компанией». В модуле «Агентские договоры» производится учет условий вознаграждения для агентов. Модуль «Договоры страхования» систематизирует договоры страхования по различным видам: авто, несчастный случай, имущество физических и юридических лиц и др.

Наш персонаж – страховой агент Мария. Мария сделала неплохую карьеру, сотрудничая со «Страховой компанией» на протяжении трех лет, она имеет несколько десятков агентских договоров по разным видам с индивидуальными условиями вознаграждения. Последний ее клиент, которому она предоставила скидку за счет своего комиссионного вознаграждения при оформлении полиса КАСКО, недавно стал ее мужем. После регистрации брака Мария сменила фамилию. Теперь Марии необходимо изменить фамилию в личной карточке «Страховой компании».

Мы смоделировали одну из возможных жизненных ситуаций. Что делать дальше? Приступать к тестированию? Пожалуй, рановато. На этом этапе логичнее будет разработать Use case (варианты использования) и при необходимости составить на их основе тест-кейсы. Более подробно о Use case вы можете почитать в книге А.Коберна «Современные методы описания функциональных требований к системам». В этом труде содержится много полезного материала, но в рамках функционального тестирования нам достаточно знать основной принцип применения этой техники – выделение обобщенных последовательностей действий лиц и ответов системы на эти действия. Ответы, в свою очередь, составляются на основе анализа действующих лиц и их конечных целей в различных условиях (с учетом соглашения о поведении рассматриваемой системы).

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

Почему User story удобны при тестировании страховых продуктов?

Согласитесь, к тестированию можно было бы подойти иначе. Не используя User story (особенно этап создания персонажей) и Use case, мы могли проверить функциональность модуля «Контрагенты» в плане создания, сохранения и редактирования данных, а потом завести баги в случае неверной работы какой-то части модуля. Однако, этого оказалось бы совершенно недостаточно, так как все модули тестируемого страхового ПО взаимосвязаны между собой. Изменения, внесенные в один модуль, должны быть обработаны другим модулем: так, исправления в карточке контрагента влекут за собой корректировку данных в агентских договорах, договорах страхования и в агентском портале.

Заключение

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

Таким образом, мы можем однозначно сказать: применение в тандеме техник User story и Use case оправдано в силу того, что они дополняют друг друга и позволяют не только качественно протестировать продукт, но и получить, дополнить и проверить требования в случае их наличия.