Основы пользовательских историй. Часть 4.


Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)

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

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

Не существует какой-либо установленной процедуры разбиения пользовательских историй на куски, вместимые в рамки итерации, кроме как общих положений о том, чтобы стори предоставляла вертикальный срез, определенный кусок, ценный для пользователя, проходящий систему насквозь. Однако, базируясь на недавней работе Ричарда Лоренца (Richard Lawrence), мы рекомендуем применять соответствующий набор из десяти общих паттернов разбиения пользовательской истории, как это показано в Таблице 1[11]:










































































1. По последовательностям действий. 

Определить конкретные шаги, выполняемые пользователем в рамках последовательности, и тогда реализовать последовательность поэтапно.

Как энергокомпания я хочу изменять и публиковать тарифные планы потребителю

...Я могу публиковать тарифные планы на домашний дисплей

...Я могу послать сообщение на Интернет-портал потребителя

...Я могу опубликовать таблицу тарифов на смарт-термостате потребителя


2. По вариации бизнес правил. 

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

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

...упорядочивать по почтовому индексу

...упорядочивать по домашней демографии

...упорядочивать по уровню потребления энергии


3. По основным трудозатратам. 

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

Как пользователь я хочу иметь возможность выбрать/изменить мой тарифный план с помощью энергокомпании через Интернет-портал

...Я хочу использовать Временной тариф [12]

...Я хочу использовать Предоплатный тариф

...Я хочу подписаться на Пиковый тариф [13]


4. По простоте / сложности. 

Когда команда обсуждает пользовательскую историю и она, кажется, становится все объемней и объемней (“А как насчет x? А думали ли вы об y?”), следует остановиться и спросить себя “какой наипростейший вариант мог бы сработать?” Зафиксируйте эту простейшую версию в качестве первой стори, и тогда уже сможете разбить все вариации и сложные детали в отдельные пользовательские истории.

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

...реагировать на время и продолжительность пиковых цен

...реагировать на непредвиденные изменения


5. По вариациям данных. 

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

Как энергокомпания я могу отсылать сообщения потребителям

...на английском

...испанском

...арабском и т. д.


6. По методам ввода данных. 

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

Как пользователь я могу просматривать мой уровень потребления на разных графиках

...используя гистограммы по однонедельным промежуткам

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


7. Отсрочка качеств системы. 

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

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

...интерполировать данные из последней вычитки данных

...показать настоящие данные счетчика в реальном времени


8. По операциям (пример: CRUD [14]). 

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

Как пользователь я могу управлять своей учетной записью

...Я могу создать учетную запись

...Я могу редактировать установки учетной записи

...Я могу приостановить учетную запись

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


9. По сценариям использования. 

Если сценарии разрабатывались для представления сложных взаимодействий вида “пользователь-система” или “система-система”, то стори часто можно разделить соответственно отдельным под-сценариям.

Я хочу подписаться на программу энергосбережения через розничного дистрибьютора.

Сценарий / Стори №1 (оптимистичный сценарий): Сообщить энергокомпании, что у пользователя есть оборудование


Сценарий / Стори №2: Энергокомпания обеспечивает оборудование и данные и уведомляет потребителя.


Сценарий / Стори №3 (альтернативный сценарий): Обработать ошибки при валидации данных.


10. Запустить спайк. 

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



Таблица 1. Десять паттернов разбиения пользовательской истории

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


ПРОДОЛЖЕНИЕ СЛЕДУЕТ...


----------------------------------------

Литература

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Martin, Robert. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Boston: MA: Pearson Education.
Poppendieck, Mary, and Tom Poppendieck. 2007. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley.
Jeffries, Ron. 2001, August. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine.

----------------------------------------

11. Адаптировано из статьи Ричарда Лоренца: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

12. Примечание автора перевода: в США потребители электроэнергии могут воспользоваться временным тарифом (time-of-use pricing), который предполагает разные тарифы в разные периоды времени (обычно года; тарифы заранее известны потребителю) и, таким образом, позволяет оптимизировать объем платы за энергию.

13. Примечание автора перевода: Пиковый тариф (Critical Peak Pricing) отражает отношение к себестоимости энергии и позволяет потреблять по “оптовым” тарифам в момент высокой загруженности сети.

14. Примечание автора перевода: Create Read Update Delete – Создание Чтение Обновление Удаление, - сокращенное название базовых функций управления данными.

No comments:

Post a Comment

 
Powered by Blogger