2014/05/05

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations 


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.
(Примечание автора: Как в случае с шаблонами любого языка, я не придумывал их, я только наблюдал и объединил их. Например, Ласс Коскела (Lasse Koskela) на сайте radio.javaranch.com дает имена некоторым шаблонам, которые я заметил, но не назвал, в частности, “Весомое усилие.”)

Насколько маленькая? 

Насколько мелкой должна быть история? Я рекомендую 6-10 историй за итерацию, так что насколько большими они должны быть зависит от скорости разработки (velocity) вашей команды. Перед следующем планированием Спринта, подсчитайте, какая оценка должна сигнализировать,что историю нужно разделить. Для большинства команд это будет 8 или 13. Но на своем последнем проекте мне было необходимо разделять истории и в 5 стори-поинтов. Когда вы во время планирования попадаете в оценку, сигнализирующую о необходимости разделения историй, возьмите список подсказок, находящийся в конце этой статьи, и попробуйте применить несколько шаблонов, пока не подберете хорошее разделение.

Какой шаблон использовать 

Вы часто будете замечать, что можете разделить истории, используя несколько шаблонов. Какое разделение стоит выбрать? Я использую два правила :

  1. Выбирайте разделение, которое позволит понизить приоритет или отбросить историю. Принцип 80/20 гласит, что бОльшая часть ценности истории реализовывается небольшой частью функциональности. Бывает, что один способ разделения историй позволяет выявить истории с низкой ценностью, а другой способ - не позволяет этого сделать. Это значит, что при использовании второго разделения каждая из новосозданных историй будет содержать в себе напрасные потери. Продолжайте разделять используя другой шаблон, который позволит отбросить то, что имеет низкую ценность. 
  2. Выбирайте разделение, которое даст вам наиболее равные по размеру истории. Раздеделение, превращающее историю в 8 стори-поинтов в 4 истории по 2 стори-поинта, намного полезней, чем разделение на 5 и 3. Оно дает Владельцу Продукта больше свободы для приоритизации отдельных частей функциональности.

Шаблон #1: Шаги рабочего процесса (Workflow Steps)

Приведу пример истории системы управления контентом (content management system), которую делал один из моих клиентов:
Как контент менеджер, я могу публиковать новость на корпоративном сайте.
Она не выглядела слишком большой — до тех пор, пока вы не углубились в шаги, необходимые для публикации новости. Оказалось, что для публикации нескольких строк новостей на корпоративном сайте требовалось разрешение редакторов и юристов, а также финальная проверка на отладочном (staging) сайте. Невозможно поместить в одну итерацию 6-10 историй такого типа.
В случае такого рабочего процесса, наибольшая ценность часто исходит из начала и конца. Промежуточные шаги добавляют ценность инкрементально, однако, не предоставлляют ценности отдельно от других шагов. Потому может оказаться эффективным реализовать простой сценарий, охыватывающий цепочку от начала до конца, а потом добавить в него промежуточные шаги и особые случаи.
Новая история включала:
… я могу публиковать новость напрямую на корпоративном сайте.
… я могу публиковать новость с рецензией редактора.
… я могу публиковать новость с рецензией юриста.
… я могу просмотреть новость на отладочном сайте.
… я могу опубликовать новость с отладочного сайта на основном сервере.

Шаблон #2: Варианты бизнес-правил 

Следующая история имеет несколько скрытых историй, которые позволяют достичь одного и того же, используя разные бизнес-правила:
Как пользователь, я могу искать рейсы с гибкими датами.
Углубление в понятие “гибкие даты” выявит несколько разных бизнес-правил, каждое из которых само по себе может быть хорошей Пользовательской Историей:
… “N дней между X и Y”
… “выходные в декабре”
… “± N дней от X и Y”.

Шаблон #3: Основное усилие 

Порой истории можно разделить на несколько частей таким образом, что основные усилия будут направлены на разработку первой истории. Например, история обработки кредитных карт вроде:
Как пользователь, я могу оплатить мой билет картами VISA, MasterCard, Diners Club или American Express
может быть разделена на 4 истории, по одной для каждого типа карты. Но механизм обработки платежей будет создан именно во время работы над первой историей, добавление же остальных видов карт уже будет являться тривиальной задачей. Мы могли бы дать первой истории более высокую оценку, но в этом случае нам нужно не забыть поменять оценку, если Владелец Продукта позже изменит приоритеты. Потому лучше отложить решение о том, какой тип карты будет реализован первым, например:
… я могу оплатить одной из карт (VISA, MC, DC, AMEX).
… я могу оплатить всеми четырьмя картами (VISA, MC, DC, AMEX) (предполагается, что оплата одной из карт уже релизована).
Две созданные истории по-прежнему не являются независимыми, но их зависимость гораздо прозрачнее, чем если бы мы создали по одной истории для каждого типа карт.

Шаблон #4: Простые/Сложные 

Во время обсуждения истории на планировании, история становится все больше и больше (“а как насчет Х?”; “ты учел Y?”). Остановитесь и спросите “Как сделать это максимально просто?”. Запишите этот простой способ как отдельную историю. Вероятно, вам также на месте придется определить ее критерии завершенности, чтобы она оставалась простой. А потом разделите все вариации и сложности на отельные истории. Вот, к примеру, история:
Как пользователь, я могу искать рейсы между двумя пунктами назначения.
будет оставаться простой, если вынести в отдельные вариации историй
… определяя максимальное количество пересадок.
… включая ближайшие аэропорты.
… используя гибкие промежутки дат.
… и т.д.

Шаблон #5: Вариации данных 

Сложность историй может обусловливаться вариантами данных. Например, системе, над которой я сейчас работаю, необходимо смоделировать георафические области, которые обслуживаются поставщиками транспортных услуг (перевозчиками). Мы могли бы потратить весь бюджет только на то,чтобы предоставить системе географические данные; да, потенциально это настолько сложно. Когда я обсуждал историю
Как пользователь, я могу искать перевозчиков по месту отправляения и месту назначения.
с нашим Владельцем Продукта, я понял, что пока мы не создадим развитую географическую информационную систему (Geographic Information System, GIS), моделирование географии будет оставаться достаточно сложным. Мы остановились и спросили: “Как мы можем построить минимально удовлетворяющую нас географическую модель, чтобы сконцентрироваться на другой ценной функциональности?” Мы сошлись во мнениях на варианте
Как пользователь, я могу искать перевозчиков по стране отправления и стране назначения.
Это помогло на некоторое время, пока мы не собрали больше данных и не выяснили, что некоторые перевозчики обсуживают определенные города или даже районы. Новая история выглядела так:
Как пользователь, я могу искать перевозчиков по странам, городам или районам отправления и назначения.
Это привело нас к следующей формулировке:
Перевозчики могут обслуживать разные георгафические области в качестве пунктов отправления и назначения. Все три истории были созданы путем разбиения первоначальной истории. Отличие здесь состоит в том, что мы добавляли историю сразу после создания наиболее простого ее варианта. Но иногда вариации данных лежат на поверхности. Классические истории локализаций:
Как контент менеджер, я могу добавлять новые новости
… на английском.
… на японском.
… на арабском.
… и так далее.

Шаблон #6: Методы введения данных 

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

Шаблон #7: Отложите производительность 

Иногда значительная часть усилий тратится на то, чтобы сделать функционал быстрым, при этом основная разработка не является такой сложной. Но вы можете выиграть больше, разработав медленную функциональность, которая уже будет иметь некую ценность для пользователя и позволять ему делать то, что иначе было бы еще невозможно. В таком случае разбейте историю на “заставить работать” и “сделать быстрой”:
Как пользователь, я могу искать рейсы между пунктами отправления и назначения.
… (медленно — просто сделать поиск, показывать анимацию “в процессе”)
… (меньше чем за 5 секунд).

Шаблон #8: Операции (например, CRUD) 

Слово “управлять” в истории использования показывает, что история покрывает несколько операций. Таким образом, нам предлагается очевидный путь разделения истории, например:
Как пользователь,я могу управлять моим аккаунтом.
… я могу войти в систему, используя мой аккаунт.
… я могу редактировать настройки моего аккаунта.
… я могу удалить мой аккаунт.

Шаблон #9: Отделение Спайка (Spike) 

Пользовательская История может быть большой не только из-за высокой сложности, но и по причине неточного понимания ее реализации. В этом случае никакой из подходов не позволит вам ее разбить. Поэтому сначала сделайте ограниченный во времени спайк, который позволит разрешить все неопределенности разработки. После этого вы сможете приступить к разработке или придумать, как можно разделить историю. Не знаете, как сделать следующую историю?
Как пользователь, я могу оплатить заказ с помощью кредитной карты.
Тогда разделите ее на:
Исследовать обработку кредитных карт.
Реализовать обработку кредитных карт.
В “исследовательской” истории критерием завершенности должен быть вопрос, на который вы пытаетесь ответить. Сделайте минимально необходимое исследование, которое позволит ответить на вопрос, и остановитесь; во время исследования очень легко отклониться от первоначальной цели.
Шаблон отделения спайка описан последним в этой статье, потому что к этому подходу следует прибегать лишь в крайнем случае. Вероятней всего, вы знаете достаточно для того, чтобы хоть что-то разработать. Сделайте это — и вы узнаете больше. Так что постарайтесь применить какие-то из предыдущих восьми шаблонов, прежде чем отделять спайк.

Заключение 

Не поддавайтесь искушению разделить Пользовательские Истории по архитектурным слоям. Вместо этого попробуйте приведенные выше шаблоны, чтобы разделить вашу историю на более мелкие, которые будут следовать INVEST модели. Дайте мне знать, помогли ли вам мои шаблоны или если вам встретились неделимые истории (я люблю трудности!).

Здесь можно скачать подсказки по разделению историй: Story Splitting in Russian (or, Как Разделять Истории Пользователей)


Переведено с английского проектом Agile Translations  
Дарья Ершова, Светлана Каща, Сергей Гердов

Оригинальная статья: "Patterns for Splitting User Stories"  by Richard Lawrence

No comments: