Сегодня я хочу поговорить об одной из самых часто искажаемых ценностей Agile-манифеста: “Готовность к изменениям важнее следования первоначальному плану”.

К сожалению эта ценность чаще всего используются для манипулирования командой, когда нужно исправить чужие ошибки. Чаще всего это происходит, когда бизнес проекта не имеет четкой стратегии развития своего продукта и не строит долгосрочную дорожную карту (roadmap). Когда в проекте нет хорошей бизнес-проработки нового функционала, когда отсутствует анализ метрик и тестирование гипотез, а все фичи берутся только из собственных соображений или подсматриваются у конкурентов, без анализа подходят ли они этому продукту, и сразу передаются исполнителям в разработку. Отсутствие приоритетов и дорожной карты (следовать плану ведь не нужно, так написано в Agile-манифесте) приводит к тому, что фичи начинают соревноваться друг с другом. И среди этого бардака приходит очевидное объяснение - готовность к изменениям важнее следования первоначальному плану. Это читается, как мантра, плохими владельцами продукта в оправдание того, что у них нет долгосрочных планов на продукт и того, что фичи и изменения приходится вставлять в середине спринта с мотивировкой, что команда должна быть готова к изменениям. Таким образом вместо гибкости мы получаем хаос. Давайте разбираться почему это неправильно и как должно быть.

В своей статье “Принципы правильной трактовки Agile-манифеста” я уже говорила о частой ошибке, когда ценности и принципы Agile трактуются как противопоставления, где одно исключает другое. Повторюсь: одно не исключает другое. Готовность к изменениям не означает, что долгосрочный план развития продукта должен отсутствовать в принципе и то, что ему не нужно следовать. Фичи не должны придумываться в последний момент и первый раз обсуждаться на планировании спринта, в котором они будут разрабатываться. И уж тем более они не должны на постоянной основе вноситься в середине спринта. Внесение внезапной фичи в процессе спринта должно быть экстренной ситуацией, а не привычной практикой.

Долгосрочный план развития продукта должен быть и продукт должен по нему двигаться. Это гарантирует то, что бизнес понимает зачем он делает этот продукт, какие потребности есть у его пользователей и в каком направлении этот продукт должен развиваться, гарантирует то, что у бизнеса есть стратегия (отличная от “посмотрим как пойдет на этой неделе”). Это залог успеха продукта, такие вещи строятся на анализе рынка, анализе собственных пользователей и конкурентов, на экспериментах и данных. Продукт без цели и без плана обречен развиваться случайным образом и деградировать технически из-за постоянного потока срочных, непоследовательных задач, заходя в тупик.

Гибкость Agile должна помогать проекту быть готовым к изменениям рынка и помогать быстро подстраиваться под них. Рассмотрим как это должно работать на самом деле. Бизнес, как владелец бэклога, наполняет его бизнес-задачами. У каждой такой задачи должен быть однозначный, желательно уникальный, приоритет. Бизнес четко должен понимать, что фича А для продукта важнее фичи Б, потому что он владеет всеми метриками и именно по ним он заранее определил, столько денег компания заработает с фич А и Б, на сколько конверсия вырастет с фич А и Б, сколько пользователей продукт потеряет, если не выпустит вовремя фичи А и Б, сколько будет стоит разработка фич А и Б, и так далее.

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

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

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

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

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

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