Автор статьи: Артем Михайлов

Привет, Хабр!

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

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

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

Переход к анти-Agile: когда структура важнее гибкости

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

Основные отличия анти‑Agile от Agile:

1. Структура vs. Гибкость: Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.

2. Индивидуальные итерации vs. Полное планирование: В Agile команды работают над небольшими итерациями и могут менять направление в зависимости от фидбэка. В анти‑Agile акцент делается на планировании всей работы заранее.

3. Командная самоорганизация vs. Четкие роли: Agile подразумевает, что команды сами определяют, как работать, тогда как в анти‑Agile каждая команда имеет четко определенные роли и обязанности.

4. Постоянное взаимодействие с клиентом vs. Фиксированные требования: Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.

Если вы находитесь в ситуации, когда Agile перестал быть полезным, и решили перейти на анти‑Agile, вот несколько шагов, которые могут помочь в этом процессе:

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

2. Создайте четкую структуру: Установите четкие роли и обязанности. Каждый член команды должен знать, за что он отвечает.

3. Планируйте заранее: Создайте детальный план на все этапы разработки. Определите сроки и ключевые точки контроля.

4. Документируйте все требования: Убедитесь, что все требования фиксируются в начале проекта.

5. Проводите регулярные проверки: Устанавливайте регулярные контрольные точки для оценки выполнения задач.

6. Обратная связь: Хотя анти‑Agile акцентирует внимание на строгих процессах, важно сохранять механизмы фидбека.

Альтернативы Agile

Также иногда стоит рассмотреть альтернативные подходы, которые могут быть более эффективными на поздних стадиях разработки:

1. Waterfall: Традиционный подход, который подразумевает последовательную реализацию этапов разработки. Он отлично подходит для проектов с четко определенными требованиями и сроками. Например, если вы разрабатываете продукт с фиксированной спецификацией.

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

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

4. Feature‑Driven Development: Этот подход фокусируется на построении функциональности по определенным фичам, что позволяет поддерживать четкую структуру и управление проектом. FDD хорошо работает в среде с большой командой.

5. SAFe: Это комплексный подход, который позволяет масштабировать Agile на уровне целой организации.

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

Однако, когда проект стал расти, требования начали изменяться, а команда — увеличиваться. Каждое новое изменение требовало переосмысления, а постоянные изменения приводили к конфликтам. Началась путаница в требованиях, сроки начали срываться, и вместо прогресса мы получили лишь бесконечные собрания и обсуждения. Здесь Agile, кажется, показал свои слабые стороны.

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

Заключение

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

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

Больше про управление командами, продуктами и проектами эксперты OTUS рассказывают в рамках практических онлайн-курсов. Смотрите все программы в каталоге, а также приходите на открытые уроки:

• 7 октября: «Организационная структура компании: типология, плюсы и минусы, подход к выбору». Записаться

• 14 октября: «Продуктовая экосистема. Почему без нее нельзя построить успешный продукт?». Записаться