Как иметь дело с историями, которые разделяют функциональность

У меня есть две истории (я знаю, что они упускают часть выгоды)

1. Как пользователь управления кредитами, я могу просматривать текущие и предыдущие различия в заработной плате для офисов.
2. Как пользователь управления кредитами, я могу получить электронное письмо, содержащее PDF с текущими и предыдущими различиями в заработной плате для офисов

Они связаны тем, что у них будут одинаковые критерии запроса / фильтра. Единственное отличие состоит в том, что в журнале «Просмотр» результаты отображаются пользователю, а в журнале «Электронная почта» результаты записываются в PDF-файл, который отправляется пользователю по электронной почте.

Я борюсь с разделением общих аспектов этих двух историй или даже должен ли я это сделать.

Например, у них обоих будет один и тот же запрос, то, что они делают с результатами, отличается.

Должен ли я разделить запрос на другую историю, которая носит чисто технический характер?

Создание PDF-файла и отправка электронного письма должны осуществляться в автономном режиме, это должно стать технической историей?

Я видел разбивку этих двух историй на две функциональные истории и две технические истории.

1. Как Система, я могу рассчитать разницу в текущей и предыдущей платежной ведомости для Офисов.

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

3. Как Система, я могу создать PDF документ о различиях текущей и предыдущей заработной платы для Офисов.

4. Как пользователь по управлению кредитами, я могу запросить получение электронного письма, содержащего PDF различий в текущей и предыдущей платежной ведомости для офисов.

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

Так что я не совсем уверен, как бороться с этими двумя.

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

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

Не делайте: попробуйте разделить истории, сделайте одну историю, а затем другую.

Сделайте: Убедитесь, что команда разработчиков знает о второй истории.

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

Цель пользовательских историй - сделать вещи. Элегантность - это вторичная цель, и ее следует оставить на рефакторинг.

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

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

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

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

• Критерии приемки
• Предположения

Строго говоря, пользовательские истории - это обещание разговора, чтобы понять требуемый результат.

Например, принимая ваш второй пользовательский рассказ

Как пользователь управления кредитами, я могу получить электронное письмо, содержащее PDF с текущими и предыдущими различиями в заработной плате для офисов

Подумайте о следующем:

• Что такое «потребность» пользователя, которая определяет это требование? (Пришло ли от них PDF в электронном письме в качестве решения? Это может не удовлетворить потребности, и ваша команда может найти лучшее решение)
• Каков минимальный срез, который может удовлетворить эту потребность пользователя и подтвердить ваше решение? Короткие петли обратной связи ценны.

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

1. Я независимый
2. По договоренности
3. V разрешимый
4. E stimatable
5. С Молл
6. T ESTABLE

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

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

TL; DR

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

Истории должны быть разложены на итерационные задачи

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

Как вы указали в своем сообщении, весьма гибкая (и на самом деле желательная) гибкая итерация содержит тесно связанные пользовательские истории. В Scrum это проявляется в использовании цели Спринта. За рамками Scrum часто все еще имеет смысл добавлять связанные истории из- за их общих целей или общих зависимостей. Извлекая и затем работая над общими зависимостями в пределах одной итерации, группы часто могут избежать необходимости рефакторинга или итерации по коду для похожих, но не идентичных функций в будущем.

Задачи Реализации Истории

Вот еще один способ подумать о планировании зависимостей для пользовательских историй. В целом:

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

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