Разбивка по границам данных

Лучше всего разбивать большие пользовательские истории по данным, которые будут поддерживаться. Например, в одном из проектов команда разрабатывала продукт, предназначенный для сбора финансовой информации. Она начала с одной крупной пользовательской истории: «Как пользователь я могу вводить информацию из моего баланса». Баланс в данном случае мог иметь очень много полей. На самом высоком уровне в нем находятся активы и пассивы. Активы содержат такие статьи, как денежные средства, ценные бумаги, объекты недвижимости, автомобили, кредиты. Система позволяла пользователю работать с этим балансом на различных уровнях детализации. Пользователь мог ввести одну сумму, представляющую все его активы. Или он мог ввести более детальную информацию (подробное перечисление всех кредитов). Вывод множества полей на экран и взаимодействие между этими полями представляли задачу значительно более крупную, чем команда, по ее оценкам, могла реализовать за одну двухнедельную итерацию.

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

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

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

Разбивайте большие истории по границам данных, поддерживаемых историей.

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

В некоторых случаях большую историю можно значительно уменьшить, удалив из основной истории обработку исключительных или сбойных ситуаций. Допустим, вы работаете над системой для обработки погашений кредитов и имеете такую пользовательскую историю: «Как заемщик я хочу иметь возможность погасить мой кредит». Когда команда обсуждала эту историю, владелец продукта подчеркнул, что в случае нечаянной отправки заемщиком чека, превышающего сумму непогашенного остатка, необходимо распечатать чек на возвращаемую сумму и отправить обратно заемщику. Он добавил, что это относится только к суммам более $2. Эту историю можно разбить на следующие, более мелкие истории:

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

• Как заемщик я в случае ненамеренной переплаты получаю возврат излишка, если он превышает $2.