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

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

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

РЕГИСТРАЦИЯ

Отказ от ответственности: Этот пост был извлечен из внутреннего документа Codurance, используемого, чтобы помочь нашим ученикам узнать, как мы работаем. Мы все понимаем, что каждый проект отличается от других и что мы ни в коем случае не можем применять везде одни и те же методы и практики. Тем не менее, текст ниже служит не только основой, но и руководством для всех нас, когда речь идет о пользовательских историях. Есть много хороших книг и постов, написанных о пользовательских историях. Это ни в коем случае не означает, что этот пост является кратким описанием всех передовых методов в этой области.

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

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

Сбор требований

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

Жизненный цикл истории пользователя

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

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

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

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

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

История должна иметь следующее:

1. Значение, которое оно приносит бизнесу (или конкретному действующему лицу / роли)
2. Подробное описание ожидаемого поведения желательно с некоторыми примерами, если применимо.
3. Критерии приемлемости, это означает, что все, что должно быть сделано командой разработчиков, чтобы владелец продукта мог «принять» историю (согласиться, что история закончена).

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

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

Наш предпочтительный шаблон:

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

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

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

Пример Story 1: Оплата кредитной картой

Пример Story 2: Плейлисты

Дальнейшее чтение: спецификация на примере

Разбивая истории на задачи

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

Задание для примера Story 2: Плейлисты

Давайте предположим, что мы создаем веб-приложение с AngularJS во внешнем интерфейсе и Java, Dropwizard и MongoDB во внутреннем.

1. Определите API, используемый внешним интерфейсом.
2. Изменения пользовательского интерфейса для захвата нового имени списка воспроизведения (см. Макет)
3. Конечная точка Dropwizard для создания списка воспроизведения
4. Сервис плейлистов / интерфейс репозитория
5. Сохранение плейлиста на MongoDB
6. Изменения в интерфейсе для добавления песен в плейлист (см. Макет)
7. Конечная точка Dropwizard для добавления песен в плейлист
8. Сохраненные песни добавлены в плейлист в MongoDB

Должны ли предметы 7 и 8 быть частью этой истории? Краткий ответ – нет . Несмотря на взаимосвязь, задачи представляют собой две разные концепции: создание списков воспроизведения и добавление песен в списки воспроизведения. Подробнее об этом ниже.

Разбивать истории на маленькие истории

Иногда мы знаем, что нужно разбить историю на более мелкие истории, просто взглянув на название или описание. Например: обработать сделку, музыкальный проигрыватель и т. Д. Какой тип торговли? Сколько типов у нас есть? У них разные правила? Даже обработка одной сделки может быть огромной. Нужно ли нам обогащать данные? Нужно ли нам сообщать о торговле различным регуляторам? Сделки идут из одного источника? У них одинаковый формат? У нас также может быть множество вопросов о музыкальном проигрывателе. Мы играем музыку, которая хранится локально? Мы в потоковом режиме? Если да, то из каких источников? Сколько форматов мы должны поддерживать? Должны ли мы быть в состоянии перемотки вперед, паузы и перемотки? Мы начинаем играть песню с того места, где остановились ранее? Отображаем ли мы какую-либо информацию о воспроизводимой песне? Если да, откуда мы получаем информацию?

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

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

Что происходит, когда владелец продукта не знает ответа?

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

Предварительный расчет

Существует большая дискуссия об оценке. Тем не менее, дебаты больше касаются оценки в целом, в основном это большие предварительные оценки (ищите #noestimates hashtag в Twitter для получения дополнительной информации).

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

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

1. Определите API, используемый интерфейсом (2 часа)
2. Изменения интерфейса для захвата нового имени плейлиста (3 часа)
3. Конечная точка Dropwizard для создания плейлиста (2 часа)
4. Сервис плейлистов / интерфейс репозитория для добавления плейлистов (2 часа)
5. Сохранение плейлиста на MongoDB (1 час)
6. Изменения интерфейса для добавления песен в плейлист (12 часов)
7. Конечная точка Dropwizard для добавления песен в плейлист (2 часа)
8. Сохраненные песни добавлены в плейлист в MongoDB (1 час)
9. [ДОБАВЛЕНО] Сервис плейлистов / интерфейс хранилища для добавления песен в плейлист (3 часа)
10. [ДОБАВЛЕНО] Уведомление о создании нового плейлиста (2 часа)
11. [ДОБАВЛЕНО] Уведомление о добавлении песни в плейлист (2 часа)

Оценка побочных эффектов

Пытаясь оценить задачи, мы поняли, что забыли несколько задач (9, 10 и 11), поэтому мы добавили их. Общее количество часов для этой истории составляет 32 часа. Добавление дополнительных заданий дало понять, что эта история должна быть разбита на две части: создавать списки воспроизведения и добавлять песни в списки воспроизведения.

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

Насколько маленький маленький?

Подумайте о принципе единой ответственности (SRP). Да, один из SOLID. Наши пользовательские истории должны представлять собой единую, небольшую и проверяемую концепцию.

Как правило, история не должна превышать 1/3 (одну треть) итерации. Это означает, что если вы работаете над двухнедельной итерацией, истории не должны превышать 3 дня. Задачи, с другой стороны, не должны превышать полдня (от 2 до 4 часов).

Шипы

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

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

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

Шипы не должны быть частью истории

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

Спайк – это особый тип истории, где ценность – лучшее понимание того, что или как можно достичь.

Технические истории

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

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

Технические истории довольно распространены в начале проекта. Есть много вещей, которые должны быть на месте, прежде чем мы начнем работать. Например, непрерывная интеграция, среда UAT / Test, контроль исходного кода и т. Д. Существует также множество инфраструктурных / архитектурных работ, которые необходимо выполнить, чтобы удовлетворить первые истории. Например, создавать базы данных, упаковывать и развертывать приложение и т. Д. Кроме того, всегда существуют нефункциональные требования, которые также необходимо соблюдать. Например: производительность, безопасность, ведение журнала и т. Д.

Экспресс стоимость бизнеса

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

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

Технические и бизнес истории

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

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

ВКЛАДЫВАТЬ ДЕНЬГИ

Мнемоника INVEST была создана Биллом Уэйком как напоминание о характеристиках пользовательской истории хорошего качества, которую можно использовать в проекте Scrum backlog или XP.

• Я не зависим: пользовательская история должна быть автономной, чтобы не было внутренней зависимости от другой пользовательской истории.
• Обсуждаемые: пользовательские истории, вплоть до того, что они являются частью итерации, всегда могут быть изменены и переписаны.
• Доступно: пользовательская история должна приносить пользу конечному пользователю.
• E stimable: у вас всегда должна быть возможность оценить размер пользовательской истории.
• Возможность оценки (небольшого размера): пользовательские истории не должны быть такими большими, чтобы стало невозможно планировать / выполнять задачи / расставлять приоритеты с определенным уровнем уверенности.
• Тестируемый: пользовательская история или связанное с ней описание должны предоставлять необходимую информацию, чтобы сделать возможной разработку теста.

Чтобы узнать больше об ИНВЕСТ, зайдите на страницу Википедии

Почему мы должны заботиться обо всем этом?

Есть несколько причин, почему мы делаем все то, что описано выше:

• Видимость: Работа с небольшими приращениями обеспечивает хорошую видимость того, что было сделано, что делается и что еще предстоит сделать. Задачи и истории постоянно находятся в движении, быстро перемещаясь по различным полосам на наших досках Scrum, от TO DO до DONE .
• Обратная связь: Бизнес и команда разработчиков постоянно говорят о том, как идут дела. Это позволяет как быстро реагировать, так и менять приоритеты. Если с историей что-то пойдет не так, мы можем потерять несколько часов или дней работы, а не недели или месяцы.
• Моральный дух команды: Моральный дух всегда на высоте, когда мы постоянно достигаем целей, то есть выполняем задачи и истории.
• Гибкость: работа небольшими партиями позволяет нам часто развертываться, быстро получать обратную связь и адаптироваться при необходимости.
• Организация команды: с четко определенными и небольшими историями и задачами легче разделить и распараллелить работу.

О чем речь? User Story в переводе с английского означает «пользовательская история». Ее задача – как можно более понятно описать особенности конкретного продукта, его функциональные возможности и ценность для конечного потребителя.

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

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

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

• Что они делают?
• Зачем?
• В чем заключается ценность разработки?

Скачать
файл

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

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

Задачи, решаемые User Story

Сразу отметим, что создание User Story имеет огромную важность, так как решает большое количество задач:

• Рассказывает о потребностях целевой аудитории.
• Оказывает содействие в группировке потребностей на задачи для разработчиков проекта.
• Принимает участие в оценке ресурсов, которые пригодятся в работе.
• Делает контекст задачи максимально понятным для всех участников команды.
• Является базой, на основании которой будет проводиться тестирование с настоящими пользователями.
• Дает возможность правильно расставить приоритеты среди поставленных разработчиками задач.

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

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

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

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

• Фокус на пользователе. Разработка приложения – это не просто последовательное выполнение дел, а решение проблем целевой аудитории.
• UserStory дает возможность коллективу работать слаженно. Главная задача заключается в определении преимущественного решения для пользователя, а также лучшего способа решения сформулированной задачи.
• Пример удачной UserStory – это документ, который позволяет находить нестандартные решения. С ее помощью разработчики определяют критический и творческий подход к выбору наилучшего пути достижения конечной цели.

  

  

  Читайте также

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

Простой шаблон User Story

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

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

Есть смысл детального рассмотрения шаблона:

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

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

Если говорить простым языком, то пользовательская история – это ответ на 3 вопроса, которые укомплектованы в одно предложение:

• Кто является пользователем приложения?
• Что он будет с ним делать и какой результат получит?
• В чем заключается цель использования?

Чтобы стало понятнее, рассмотрим конкретные примеры:

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

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

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

Критерии INVEST для User Story

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

• Independent (Независимый)

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

• Negotiable (Обсуждаемый)

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

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

• Valuable (Ценный)

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

• Estimable (Оцениваемый)

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

• Small (Компактный)

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

• Testable (Тестируемый)

Любая User Story нуждается в тестировании. Необходимо убедиться, что она действительно имеет что-то такое, что можно реализовать.

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

• Пользовательская история должна быть краткой. Если объем больше, чем допустимый, лучше выполнить написание нескольких маленьких UserStory.
• Авторами пользовательской истории должна быть вся команда разработчиков. Так, вы не упустите ценные нюансы и доведете User Story до совершенства.

  

  

  Читайте также

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

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

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

7 распространенных ошибок при составлении User Story

• Предположим, что вы написали качественную UserStory, которая полностью отвечает критериям INVEST и успешно прошла тестирование. Вы считаете, что работа по созданию истории выполнена. Но в один момент ваш клиент решил изменить требования. Если вы не внесете изменения, пользы будет мало. Поэтому, даже если результат превзошел все ожидания, корректировки все же нужно сделать.
• Как бы хорошо не была написана история, старайтесь, чтобы она была понятна не только для вас и заказчика. Использование специфических и профессиональных терминов является нежелательным. Также следует избегать аббревиатур и сокращений.
• Полный лист формата А4 – это много для пользовательской истории. Перечитайте ее и подумайте, какие данные лишние?
• Если у продукта несколько типов пользователей, это нужно отразить в истории. Многие разработчики пишут UserStory лишь для одного типа, тем самым не раскрывают полностью ценность продукта.
• Вы перегружаете свой бэклог историями, вследствие чего вам самим тяжело в них разобраться. Есть смысл навести порядок, убрать то, что уже утратило свою актуальность.
• У вас уже реализовано большое количество Story, а вот заказчики не торопятся принимать их. Но ваш успех зависит именно от последних. Поторопите владельцев продукта, если работы будут приняты слишком поздно, у вас не останется времени на редактирование.

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

Итак, User Story – это мощный инструмент, который позволяет создать нужный продукт. При использовании методики обязательно поддерживайте связь со своей командой и клиентами, а также своевременно вносите изменения.

Пользовательские истории — это задачи разработки, часто выражаемые как «персона + потребность + цель».

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

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

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

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

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

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

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

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

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

 Зачем создавать пользовательские истории?

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

Пользовательские истории служат ряду ключевых преимуществ:

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

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

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

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

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

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

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

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

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

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

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

«Как [персона], я [хочу], [так что]».

• Разбивая это:«Как [персона]»:Для кого мы это строим? Мы не просто за названием должности, мы за персоной человека. Макс. Наша команда должна иметь общее представление о том, кто такой Макс. Надеюсь, мы взяли интервью у Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. У нас есть сочувствие к Максу.
• «Хочет»: здесь мы описываем их намерения, а не функции, которые они используют. Чего они на самом деле пытаются достичь? Это утверждение должно быть свободным от реализации — если вы описываете какую-либо часть пользовательского интерфейса, а не цель пользователя, вы упускаете суть.
• «Так вот»: как их непосредственное желание сделать что-то, что вписывается в их общую картину? Какую общую выгоду они пытаются достичь? Какую большую проблему нужно решить?

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

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

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

Начало работы с Agile пользовательскими историями

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

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

По материалам Agile Coach «User Stories with Examples and Template»