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

Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.

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

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

Чтобы ответить на этот вопрос, давайте разделим это понятие на части:

• История, в данном контексте, — это «устное или письменное изложение материала в художественной форме».

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

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

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

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

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

Давайте приведем несколько примеров обычных историй для иллюстрации?

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

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

Одно из преимуществ следования этой модели заключается в том, что автор истории вынужден сосредоточиться на «ЧТО», а не на «КАК» — за последнее отвечает команда разработчиков.

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

Кто является действующими лицами или персонами в историях?

Это конечные пользователи историй. Именно они часто их пишут или запрашивают.

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

Только ли PM должен писать истории?

Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.

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

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

Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?

• A) «Не хватает кнопки загрузки».

• B) «Я бы хотел, чтобы на прикрепленном экране отображалось больше информации о продукте».

• C) «Включите больше изображений».

Один из способов превратить плохие истории в нечто полезное — использовать метод 5 Whys ( 5 “Почему«). Он также помогает автору быть более подготовленным и правильно описать свою следующую историю.

Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.

Проблема: «Не хватает кнопки загрузки».

• 1-й. Почему ?: — «Чтобы я мог скачать отчеты».

• 2-й. Почему ?: — «Чтобы я мог использовать данные в excel».

• 3-й. Почему ?: — «Чтобы я мог перепроверять информацию с данными из других источников».

• 4-й. Почему ?: — «Чтобы я мог предоставить полный отчет с информацией о продажах и доходах».

• 5-й. Почему ?: — «Совету директоров нужна точная информация о продажах и доходах, чтобы принимать важные инвестиционные решения для компании.»

Обладая этой информацией, можно было бы улучшить исходную историю, например:

• Как BI-аналитик;

• Я хочу экспортировать данные из отчета XYZ в формате CSV;

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

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

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

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

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

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

Вот совет для написания хороших критериев приемки — необходимо подумать о том, как продемонстрировать функциональность, когда она будет готова. Как это будет работать? Какие для этого нужны шаги ?

Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:

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

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

— При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;

— При нажатии на кнопку загрузка начинается автоматически;

— Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;

Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет «Agile» (гибко), если это история с 423 критериями приемки.

---

Перевод подготовлен в рамках курса «Системный аналитик. Advanced».

Всех желающих приглашаем на открытый урок «Бизнес- и системный анализ как подготовка к тестированию качества программного продукта». На этом демоуроке обсудим:
— Зачем нужны User story для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?

РЕГИСТРАЦИЯ