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