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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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