Дорожные карты agile: создание, общий доступ, использование, развитие

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

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

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

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

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

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

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

Добавляя на дорожную карту новую инициативу, следует ответить на несколько вопросов.

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

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

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

Представим, к примеру, что мы запускаем на веб-сайте возможность ведения пользовательского профиля. Если окажется, что клиенты не используют эту возможность, следует ли продолжать работу над ней? Возможно, да, а может, и нет. Прежде чем принять решение, нужно понять причины низкой востребованности этой возможности. Вместо того чтобы продолжать движение, можно остановиться и провести A/B-тестирование, по результатам которого сделать важные выводы о том, в каком направлении следует двигаться дальше. И если мы вовремя не остановимся, а продолжим упрямо добавлять излишества, вернуться на этот правильный путь будет уже гораздо сложнее (если вообще возможно).

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

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

Agile-разработка, в свою очередь, сопряжена с тремя видами рисков.

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

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

Из следующих статей цикла «Тренер по Agile» можно узнать, что должны учитывать крупные команды, управляющие портфелями проектов по методике Agile и составляющие дорожные карты для нескольких команд. Вы также можете бесплатно попробовать построить собственную дорожную карту в решении Jira Product Discovery, созданном для команд по продукту.