Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.
Одним из принципов agile-разработки является идея разбиения крупных разработок на более мелкие части, называемые историями. На пути к тому, чтобы стать ниндзя-мастером на позиции продакт-менеджера и приносить пользу клиентам с помощью своего продукта, вам придется заботиться о бэклоге и содержащихся в нем пользовательских историй.
Но что такое пользовательская история?
Чтобы ответить на этот вопрос, давайте разделим это понятие на части:
Когда мы говорим о методологии agile-разработки, пользовательская история — это инструмент, который помогает переключить внимание с детализации требований к системе на их обсуждение.
Обычно это делается с помощью предложений, в которых говорится об удовлетворении требования, например:
Как <тип пользователя>, я хочу <некоторое желание>, чтобы я мог <получить некоторую компенсацию>.
Шаблон пользовательской истории
Давайте приведем несколько примеров обычных историй для иллюстрации?
При создании новой истории автор всегда должен сосредоточиться на описании своих потребностей и цели, которую он пытается достичь с ее помощью. Благодаря этому команда, выслушав историю и не будучи ограниченной уже предложенными попытками решения, может свободно создать или предложить наилучшую альтернативу для решения проблемы.
Кто является действующими лицами или персонами в историях?
Это конечные пользователи историй. Именно они часто их пишут или запрашивают.
В примерах выше в качестве действующих лиц мы используем менеджера по маркетингу и руководителя компании, но участниками могут быть все, кто имеет отношение к вашему продукту, конечный клиент, внутренний пользователь, внешний пользователь, сам PM (продакт-менеджер) и т.д.
Только ли PM должен писать истории?
Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.
Задача PM, однако, состоит в том, чтобы убедиться, что истории хорошо описаны и содержат достаточно информации, чтобы команда могла их легко понять. Именно на основе конкретной пользовательской истории команда будет планировать свою работу и оценивать ее сложность.
Плохие пользовательские истории
Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?
Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.
Проблема: "Не хватает кнопки загрузки".
Не стоит забывать, что хорошая пользовательская история также содержит четко сформулированные критерии приемки.
Критерии приемки, как следует из названия, — это критерии, по которым история может быть принята или отклонена.
Они представляют собой набор инструкций, каждая из которых дает четкий результат «прошел или не прошел» — например, контрольный список, в котором указаны функциональные и нефункциональные требования.
Критерии приёмки в конечном результате представляют собой "Определение выполненного" и, по существу, хорошо выполненного.
Вот совет для написания хороших критериев приемки — необходимо подумать о том, как продемонстрировать функциональность, когда она будет готова. Как это будет работать? Какие для этого нужны шаги ?
Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:
Как BI-аналитик, я хочу экспортировать данные из отчета XYZ в формате CSV, чтобы предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки:
- При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;
- При нажатии на кнопку загрузка начинается автоматически;
- Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;
Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет "Agile" (гибко), если это история с 423 критериями приемки.
Источник статьи: https://habr.com/ru/company/otus/blog/566966/
Одним из принципов agile-разработки является идея разбиения крупных разработок на более мелкие части, называемые историями. На пути к тому, чтобы стать ниндзя-мастером на позиции продакт-менеджера и приносить пользу клиентам с помощью своего продукта, вам придется заботиться о бэклоге и содержащихся в нем пользовательских историй.
Но что такое пользовательская история?
Чтобы ответить на этот вопрос, давайте разделим это понятие на части:
- История, в данном контексте, — это "устное или письменное изложение материала в художественной форме".
- Пользователь — это человек, который владеет или пользуется чем-то по желанию, то есть человек, который использует компьютер, программное обеспечение, системы или компьютерные услуги.
Когда мы говорим о методологии agile-разработки, пользовательская история — это инструмент, который помогает переключить внимание с детализации требований к системе на их обсуждение.
Обычно это делается с помощью предложений, в которых говорится об удовлетворении требования, например:
Как <тип пользователя>, я хочу <некоторое желание>, чтобы я мог <получить некоторую компенсацию>.
Давайте приведем несколько примеров обычных историй для иллюстрации?
- Как менеджер по маркетингу, я хочу знать источник и механизм получения информации о том, что послужило причиной покупки на нашем сайте, чтобы понять, какие каналы коммуникации лучше всего подходят для реализации нашего продукта.
- Как руководитель компании, я хочу знать среднюю величину дохода по каждому проданному продукту, чтобы решить, куда вкладывать больше или меньше средств.
При создании новой истории автор всегда должен сосредоточиться на описании своих потребностей и цели, которую он пытается достичь с ее помощью. Благодаря этому команда, выслушав историю и не будучи ограниченной уже предложенными попытками решения, может свободно создать или предложить наилучшую альтернативу для решения проблемы.
Кто является действующими лицами или персонами в историях?
Это конечные пользователи историй. Именно они часто их пишут или запрашивают.
В примерах выше в качестве действующих лиц мы используем менеджера по маркетингу и руководителя компании, но участниками могут быть все, кто имеет отношение к вашему продукту, конечный клиент, внутренний пользователь, внешний пользователь, сам PM (продакт-менеджер) и т.д.
Только ли PM должен писать истории?
Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.
Задача PM, однако, состоит в том, чтобы убедиться, что истории хорошо описаны и содержат достаточно информации, чтобы команда могла их легко понять. Именно на основе конкретной пользовательской истории команда будет планировать свою работу и оценивать ее сложность.
Плохие пользовательские истории
Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?
- A) "Не хватает кнопки загрузки".
- B) "Я бы хотел, чтобы на прикрепленном экране отображалось больше информации о продукте".
- C) "Включите больше изображений".
Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.
Проблема: "Не хватает кнопки загрузки".
- 1-й. Почему ?: - "Чтобы я мог скачать отчеты".
- 2-й. Почему ?: - "Чтобы я мог использовать данные в excel".
- 3-й. Почему ?: - "Чтобы я мог перепроверять информацию с данными из других источников".
- 4-й. Почему ?: - "Чтобы я мог предоставить полный отчет с информацией о продажах и доходах".
- 5-й. Почему ?: - "Совету директоров нужна точная информация о продажах и доходах, чтобы принимать важные инвестиционные решения для компании."
- Как BI-аналитик;
- Я хочу экспортировать данные из отчета XYZ в формате CSV;
- Чтобы вы могли предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Не стоит забывать, что хорошая пользовательская история также содержит четко сформулированные критерии приемки.
Критерии приемки, как следует из названия, — это критерии, по которым история может быть принята или отклонена.
Они представляют собой набор инструкций, каждая из которых дает четкий результат «прошел или не прошел» — например, контрольный список, в котором указаны функциональные и нефункциональные требования.
Критерии приёмки в конечном результате представляют собой "Определение выполненного" и, по существу, хорошо выполненного.
Вот совет для написания хороших критериев приемки — необходимо подумать о том, как продемонстрировать функциональность, когда она будет готова. Как это будет работать? Какие для этого нужны шаги ?
Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:
Как BI-аналитик, я хочу экспортировать данные из отчета XYZ в формате CSV, чтобы предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки:
- При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;
- При нажатии на кнопку загрузка начинается автоматически;
- Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;
Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет "Agile" (гибко), если это история с 423 критериями приемки.
Источник статьи: https://habr.com/ru/company/otus/blog/566966/