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

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

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

Спайки

Спайки – еще одно изобретение XP – представляют собой особый тип стори, используемый для вытеснения рисков и неопределенности из пользовательской истории или определенного аспекта проектной деятельности. Спайки могут быть использованы при ряде причин:

1. У команды может не хватать знания бизнес-области и спайки могут использоваться для базовых исследований, направленых на ознакомление команды с новой технологией или бизнес-областью.
2. Стори может быть слишком большой, чтоб ее можно было соответствующим образом проэстимировать, и команда может использовать спайк для анализа подразумеваемого поведения, таким образом они могут разбить стори на эстимируемые кусочки.
3. Стори может включать в себя существенные технические риски и команде может понадобиться проведение определенных исследований, чтобы обрести уверенность в технологическом подходе, применяя который они смогут выполнить эту пользовательскую историю в будущем таймбоксе.
4. Стори может включать существенный функциональный риск и при том, что сама пользовательская история понятна, остается непонятным, как система должна взаимодействовать с пользователем, чтобы достичь ожидаемой пользы.


Технические и функциональные спайки

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

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


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


В этом случае команда может создать два спайка:

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




Рекоммендации по спайкам


Эстимируемость, демонстрируемость и возможность приемки

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

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

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


Исключение, а не правило

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

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


Реализация спайка в одном спринте, а результирующих пользовательских историй в другом

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


Моделирование стори с помощью карточек

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

В виду физически ограниченного размера карточек, возникает естественное ограничение на размер текста, требуя от создателя стори умения формулировать идеи одним-двумя предложениями. Это помогает поддерживать пользовательские истории компактными и сфокусированными – а это ключевой атрибут. Также, осязаемая физическая природа карточек дает возможность командам визуально и пространственно упорядочивать их в различной последовательности, помогая таким образом определить бэклог:

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

Любой член команды может записать пользовательскую историю на карточке и само по себе физическое действие при передвижении по столу этих компактных, осязаемых “носителей ценности”, порождает интерактивное кинестетическое обучение, когда участники “видят и осязают” пользу, которую им вскоре предстоит реализовать для стейкхолдеров.
Как показывает опыт, команды, обладающие коллективным видением, более ответственно следуют его реализации. Моделирование доставки ценности с помощью физических карточек предоставляет естественную модель подключения к работе всех членов команды и стейкхолдеров, модель, результатом которой является коллективное, осязаемое видение – каждый может его созерцать и ощущать.


Подводим итог

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

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

Литература

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.

No comments:

Post a Comment

 
Powered by Blogger