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

Отказ от ответственности: Этот пост был извлечен из внутреннего документа 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 .
• Обратная связь: Бизнес и команда разработчиков постоянно говорят о том, как идут дела. Это позволяет как быстро реагировать, так и менять приоритеты. Если с историей что-то пойдет не так, мы можем потерять несколько часов или дней работы, а не недели или месяцы.
• Моральный дух команды: Моральный дух всегда на высоте, когда мы постоянно достигаем целей, то есть выполняем задачи и истории.
• Гибкость: работа небольшими партиями позволяет нам часто развертываться, быстро получать обратную связь и адаптироваться при необходимости.
• Организация команды: с четко определенными и небольшими историями и задачами легче разделить и распараллелить работу.