Дорожные карты

Agile дорожные карты: строить, делиться, использовать, развиваться

Быть успешным не значит не знать, куда ты идешь. Это означает быть гибким в отношении выбранного вами пути.

Идея, что гибкая (agile) разработка отказывается от долгосрочного планирования, может быть самым большим мифом со времен Лох-Несского монстра. Дорожная карта так же важна для гибкой команды, как и для команды водопада, потому что она обеспечивает контекст вокруг повседневной работы команды и реагирует на изменения в конкурентной среде. Но в отличие от некоего легендарного шотландского водного зверя, гибкую дорожную карту легко найти и легко понять.

Что такое agile  дорожная карта продукта?

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

Построение дорожной карты

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

РИСУНОК

Поделиться дорожной картой

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

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

 

Так как же владелец продукта может лучше информировать команду? Просто.

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

При добавлении инициативы в план действий учтите следующие вопросы:

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

• Каковы относительные приоритеты каждой инициативы?
• Когда мы намерены работать над каждой инициативой?
• Есть ли какие-то особые даты, которые команда должна достичь? Какие зависимости имеет программа - внутренние или от других команд?
• Какие команды работают над каждой инициативой?
  • Есть ли у текущих команд доступность в их расписаниях и достаточная способность?
  • Можем ли мы сохранить текущие agile команды стабильными?
    • Если не...
      • Как команды будут реорганизованы?
        • Учитываем ли мы наращивание вновь сформированных команд в сроках проекта?

 Использование дорожной карты

Важно связать работу вашей команды с дорожной картой, чтобы вы получили весь этот «контекст», о котором я упоминал выше. Опробованный и надежный способ сделать это состоит в том, чтобы разбить инициативы на эпики в списке необходимых требований (backlog) продукта, а затем разложить их на требования и истории пользователей.

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

Скажем, например, что мы развернули обширную функцию профиля пользователя на нашем сайте. Если мы обнаружим, что наши клиенты не используют эту функцию, следует ли нам продолжать в нее инвестировать? Может быть, а может и нет. Мы должны понять, почему вовлеченность низкая, прежде чем мы примем это решение. Поэтому вместо того, чтобы идти вперед, мы могли бы предпочесть провести некоторые А / Б-тесты в надежде получить представление о низкой степени вовлеченности, что может указать нам направление, которое было бы гораздо более трудным (или невозможным), если бы мы просто пахали впереди, добавляя больше колокольчиков и свистков.

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

АНТИ-ОБРАЗЦЫ, ЧТОБЫ СМОТРЕТЬ ЗА НИМИ

• Будущее планирование полностью игнорируется - мы стреляем с бедра!
• «Остальная часть бизнеса» остается в неведении относительно того, чем занимается команда.
• Дорожная карта постоянно обновляется (или никогда не обновляется).
• Подробные требования отягощают дорожную карту.

Развитие дорожной карты

Водопадные (Waterfall) проекты требуют огромных предварительных инвестиций. В результате члены команды становятся эмоционально привязанными к дорожной карте и жертвуют тем, что принимают правильное решение, потому что слишком болезненно отменять работу, которую они сделали - «человеческий» грех, если таковой был.

Со своей стороны, agile  разработка сталкивается с тремя различными рисками:

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

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

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

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

По материалам Agile Coach "Roadmaps"