Спустя 24 года после публикации Agile Manifesto спор об Agile по-прежнему сводят к стендапам, спринтам и доскам в Jira, хотя исходный вопрос был совсем другим: как выпускать софт быстрее, не превращая кодовую базу в свалку. На этом фоне книга Роберта Мартина Clean Agile снова попала в поле зрения управленцев: как пишет Habr / Менеджмент, это не учебник по Scrum, а попытка вернуть разговор к базовым принципам, от которых зависит и срок релиза, и вменяемость бюджета.
Повод для обсуждения в целом показательный. Agile давно стал корпоративным стандартом, но в большой части компаний его практикуют как набор ритуалов без связи с исходной логикой. Роберт Мартин, более известный как Uncle Bob, здесь выступает не сторонним наблюдателем, а одним из авторов Agile Manifesto 2001 года. Поэтому его книга интересна не только разработчикам, которые спорят о качестве кода, но и project-менеджерам, product-менеджерам, тимлидам и тем, кто отвечает перед бизнесом за сроки. Главный тезис простой: Agile появился не ради красивых церемоний, а как ответ на провал тяжеловесных методов управления в среде, где требования меняются быстрее, чем успевают обновляться документы.
Самая практичная часть книги, судя по пересказу, связана с концепцией Iron Cross of Agile Management. Мартин раскладывает любой проект на четыре характеристики: качество, скорость, стоимость и объем работ. Клиент почти всегда хочет максимум по всем фронтам сразу, но такая постановка задачи существует скорее в презентациях, чем в реальной разработке. Для руководителя проекта это неприятная, но полезная мысль: его работа не в том, чтобы обещать невозможное, а в том, чтобы честно управлять компромиссами. Иначе говоря, продукт должен быть не «идеальным по всем параметрам», а достаточно качественным, достаточно быстрым, достаточно дешевым и достаточно полным, чтобы решить бизнес-задачу. Для русскоязычного IT-рынка, где менеджер нередко живет между «сделайте вчера» и «почему так дорого», тезис не академический, а вполне прикладной.
Вторая сильная линия Clean Agile бьет по еще одному популярному мифу: будто Agile нужен в первую очередь команде разработки, а менеджменту достаются только новые слова и новые встречи в календаре. У Мартина логика обратная. Velocity, burn-down chart и результаты спринта важны не для отчетности ради отчетности, а как сырье для управленческих решений. Если команда стабильно делает около 45 story points за спринт, это уже не интуиция, а точка отсчета для прогноза сроков, обсуждения приоритетов и разговора с заказчиком без шаманства. В нормальной конфигурации Agile не усложняет управление, а делает его прозрачнее: видно, с какой скоростью движется команда, насколько реалистичен план и где именно начнется срыв, если scope продолжат раздувать.
Отсюда вытекает, пожалуй, самый неудобный для бизнеса вывод: ускорение через снижение качества почти никогда не работает. Мартин прямо спорит с подходом «сейчас напишем быстро и грязно, а потом разберемся». За десятилетия в индустрии, по его оценке, такая схема не дала настоящего выигрыша ни одному проекту. Плохой код быстро превращается в процент по техническому долгу: растут ошибки, усложняется поддержка, любое изменение стоит дороже, а команда тратит время не на продукт, а на разминирование собственного прошлого. Для компаний, где сроки регулярно горят, это звучит почти как ересь, потому что первая реакция обычно предсказуема: урезать тестирование, закрыть глаза на архитектуру и попросить людей «немного поднажать». Но именно этот рефлекс потом и делает следующий релиз еще медленнее.
В этой точке Agile у Мартина становится не философией, а вполне жесткой управленческой дисциплиной. Если дедлайн не сдвигается, менять нужно не качество, а объем работ. Сначала в релиз идут функции с максимальной ценностью для бизнеса, остальное переносится дальше. Для менеджера это означает неприятный, но здоровый разговор о приоритетах: какие задачи действительно влияют на результат, а какие оказались в бэклоге потому, что всем было неловко сказать «нет». Такой подход часто выглядит менее героически, чем ночные переработки и авральные фиксы, зато дает работающий продукт в срок и не убивает команду на дистанции. В российских и русскоязычных командах, где культура переработок до сих пор нередко маскируется под «вовлеченность», этот тезис звучит особенно трезво.
Не менее важен и раздел о разумных ожиданиях от команды. В пересказе Habr / Менеджмент перечислены вещи, которые бизнес вправе требовать без скидок на модные методологии: плохой продукт не должен уходить в релиз, система должна оставаться технически готовой, производительность команды не должна хаотично проваливаться, изменения не должны становиться запредельно дорогими, а оценки сроков должны быть честными. Это хороший момент для всех, кто привык противопоставлять Agile дисциплине. У Мартина Agile как раз и строится на дисциплине, только не на дисциплине бессмысленных согласований, а на дисциплине инженерной работы, прозрачной коммуникации и постоянной обратной связи. Если этих оснований нет, спринты и ретро быстро превращаются в театральную постановку с Jira в роли декорации.
Финальная мысль книги, похоже, и объясняет, почему разговор о ней снова цепляет рынок. Agile у Мартина не равен Scrum, не сводится к митингам и не работает как магическая кнопка ускорения. Речь идет о наборе ценностей и практик, которые помогают принимать более точные решения в условиях изменений, не жертвуя качеством. В пересказе названы четыре базовые опоры: смелость, коммуникация, обратная связь и простота. Для разработчика это означает меньше легализованного хаоса под видом гибкости. Для менеджера - отказ от иллюзии, что процесс можно «додавить» одними KPI. А для бизнеса - неприятную, но полезную развилку: либо компания учится управлять объемом, качеством и ожиданиями, либо продолжает верить, что любой проект можно сделать одновременно быстрее, дешевле и без потерь. Именно на этой развилке и проверяется, понимают ли в компании Agile как инструмент управления реальностью или все еще принимают его за набор встреч по расписанию.