Agile в компании всё чаще выглядит не как способ быстрее делать продукт, а как набор ритуалов: стендапы, коучи, новые названия команд и календарь без воздуха. Автор Habr / Карьера разбирает, почему методология, придуманная разработчиками для защиты смысла работы, в корпорациях часто превращается в управленческий театр. Для русскоязычных IT-команд это больно знакомая история: Agile внедряют сверху, а последствия разгребают инженеры.
Поводом стала колонка «У вас не Agile» — сказал agile-коуч, сообщает Habr / Карьера. Автор начинает с типичной сцены цифровой трансформации: в компанию приходит Agile-коуч и объясняет разработчикам, QA и инфраструктурным инженерам, что они «работают неправильно». Дальше обычно появляются новые церемонии, новые роли, срочные встречи со стейкхолдерами и ощущение, что эффективность измеряют не работающим софтом, а количеством правильно заполненных досок.
Главная претензия текста не к Agile как идее, а к его корпоративной имитации. В компаниях методологию часто выбирают как универсальную таблетку для цифровой трансформации: если нужно ускориться, поднять KPI и показать движение, значит, надо «внедрить Agile». Проблема в том, что сложившуюся организацию нельзя безболезненно перестроить на ходу, особенно если бизнес-процессы, архитектура, ответственность и принятие решений остаются прежними. В итоге меняются названия, а не поведение.
Автор напоминает, что Agile-манифест появился в 2001 году, когда 17 специалистов собрались в американском Сноуберде и сформулировали ценности гибкой разработки. Среди участников были Мартин Фаулер, Роберт Мартин и Кент Бек. Это важная деталь: речь шла не о менеджерах, придумавших новый способ контролировать разработчиков, а о практиках, которым надоело месяцами делать продукт, устаревший ещё до релиза.
Кент Бек в этой истории особенно показателен. Он известен как автор eXtreme Programming, подхода, из которого в индустрию пришли или широко разошлись короткие релизы, парное программирование, разработка через тестирование и практики непрерывной интеграции. Вместе с Эрихом Гаммой Бек создал JUnit, один из ключевых инструментов для автоматизированного тестирования в Java-экосистеме. То есть исходный Agile вырос из инженерной культуры, а не из презентаций про «ускорение поставки ценности».
Отсюда и центральный конфликт. В исходной логике Agile должен был усилить голос разработки в бизнесе: инженерная команда не просто шьёт «костюм» по странному техническому заданию, а помогает понять, какая проблема решается, где требования противоречат реальности и почему иногда дешевле поменять процесс, чем писать ещё один слой костылей. Это совсем другой разговор, чем «выполняйте задачи быстрее, потому что теперь у нас спринты».
Хороший пример внедрения автор связывает с практиками ThoughtWorks, консалтинговой компании, где Мартин Фаулер с 2000 года работает Chief Scientist. В описанной модели изменения не спускаются приказом: в отдел приходит сильная инженерная команда, работает по XP-практикам, показывает результат и помогает коллегам перенимать подходы точечно. Не через обязательный культ церемоний, а через интерес, качество кода и доверие. Такой Agile в компании распространяется снизу вверх, потому что разработчики видят пользу, а не только новые встречи.
Для бизнеса вывод неприятный, но полезный: Agile нельзя купить как тренинг или должность в штатном расписании. Если у команды нет права спорить с требованиями, менять приоритеты, улучшать инженерные практики и влиять на продуктовые решения, гибкость останется вывеской. Можно назвать отдел скводом, релиз — инкрементом, а совещание — синком, но от этого система не станет быстрее думать.
Для разработчиков здесь тоже нет простого оправдания в стиле «Agile — это менеджерский бред». Исторически Agile как раз появился из инженерного недовольства плохими процессами. Поэтому вопрос не в том, нужен ли Agile в компании, а в том, кто им пользуется и зачем: чтобы дать команде больше ответственности за результат или чтобы упаковать старый контроль в модные слова. Похоже, ближайшие годы эта развилка станет только заметнее: цифровая трансформация продолжится, но команды всё чаще будут спрашивать не «по какой методологии мы работаем», а «что именно нам теперь можно решать самим».