
Многие знают Agile по ежедневным стендапам, спринтам и доскам в Jira. Но мало кто задумывается, почему Agile вообще появился. Если вам интересен ответ на этот вопрос, очень рекомендую книгу Роберта Мартина «Clean Agile. Back to Basics». Для меня это одна из лучших книг об Agile, которую стоит прочитать каждому Project Manager.
Для многих специалистов в IT имя автора не нуждается в представлении. Именно Роберт Мартин, известный также как Uncle Bob, был одним из авторов Agile Manifesto, опубликованного в 2001 году и навсегда изменившего подход к разработке программного обеспечения.
Книга получилась интересной не только для разработчиков, но и для руководителей проектов. Это не очередной учебник по Scrum или набор модных практик. Скорее, это попытка вернуться к истокам Agile и объяснить, зачем он вообще появился.
Мартин начинает с простой мысли: современный мир полностью зависит от программного обеспечения. Софт управляет практически всеми аспектами нашей жизни. Программное обеспечение стало кровеносной системой современной цивилизации. Без него привычный нам мир просто не смог бы существовать. Поэтому неудивительно, что люди, создающие программное обеспечение, постоянно ищут способы делать это быстрее, качественнее и эффективнее.
Большая часть книги посвящена истории возникновения Agile. Автор подробно рассказывает, какие проблемы существовали в индустрии до появления Agile-подходов и почему традиционные методы управления проектами перестали справляться с задачами быстро меняющегося мира разработки.
Но самое ценное в книге — не история, а практические идеи, многие из которых остаются актуальными спустя более двадцати лет.
Iron Cross of Agile Management
Одной из самых запоминающихся концепций книги для меня стал так называемый Iron Cross of Agile Management.
У любого проекта есть четыре характеристики:
качество;
скорость;
стоимость;
объем выполненной работы.
Заказчики часто хотят получить все сразу: быстро, дешево, качественно и в полном объеме. Проблема в том, что в реальной жизни так не работает.
По мнению Мартина, задача хорошего руководителя не в том, чтобы требовать максимума по всем направлениям одновременно. Его задача — находить баланс. Проект должен быть достаточно качественным, достаточно быстрым, достаточно дешевым и достаточно завершенным для достижения бизнес-цели. По сути, управление проектом — это постоянная работа с компромиссами.
Agile нужен не только команде, но и менеджерам
Многие воспринимают Agile как набор процессов для разработчиков.
Мартин смотрит на ситуацию иначе. По его мнению, одна из главных задач Agile — предоставить менеджерам данные для принятия решений.
Velocity команды, Burn-down Chart, результаты спринтов — это не просто красивые графики для отчетности. Это информация, которая позволяет понимать:
насколько быстро движется команда;
когда реально можно ожидать поставку продукта;
насколько текущий план выполним;
какие решения нужно принимать дальше.
Если средняя скорость команды составляет около 45 story points за спринт, руководитель уже может делать прогнозы по срокам и обсуждать их с заказчиком на основе фактов, а не интуиции.
Именно поэтому Agile делает процесс разработки более прозрачным как для команды, так и для бизнеса.
Единственный способ двигаться быстрее — делать качественно
Еще одна мысль, которая проходит через всю книгу, может показаться парадоксальной.
Если нужно ускориться, нельзя жертвовать качеством. Мартин пишет, что за десятилетия работы разработчиком он не увидел ни одного примера, когда подход "быстро и грязно" действительно ускорял проект. Наоборот. Плохой код приводит к ошибкам, усложняет поддержку системы, увеличивает стоимость изменений и в итоге замедляет разработку.
Поэтому его вывод звучит очень просто: единственный способ двигаться быстро — делать работу хорошо. Эта идея особенно актуальна сегодня, когда команды постоянно находятся под давлением сроков.
Если сроки горят — меняйте не качество, а объем работ
Еще один важный вывод книги связан с управлением ожиданиями.
Когда становится понятно, что команда не успевает реализовать весь первоначальный объем задач, большинство компаний пытаются:
увеличить нагрузку на сотрудников;
сократить тестирование;
упростить требования к качеству.
Agile предлагает другой путь. Менять нужно scope проекта. Сначала реализуются самые ценные для бизнеса функции. Менее важные задачи могут быть перенесены на следующий релиз.
Это позволяет сохранить качество продукта и при этом получить работающий результат вовремя. По сути, Agile предлагает управлять проектом через управление объемом работ, а не через снижение качества.
Разумные ожидания от команды
В книге есть раздел, который называется Reasonable Expectations.
Мартин перечисляет вещи, которые заказчики и менеджеры вполне справедливо ожидают от команды разработки:
мы не будем выпускать плохой продукт;
система всегда находится в технически готовом состоянии;
производительность команды остается стабильной;
изменения не стоят слишком дорого;
команда постоянно совершенствует процессы;
сотрудники помогают друг другу;
оценки сроков остаются честными.
На мой взгляд, это один из самых сильных разделов книги. Потому что здесь Agile перестает быть набором церемоний и превращается в профессиональную ответственность команды перед бизнесом и пользователями.
Что такое Agile на самом деле
В конце книги Мартин формулирует мысль, которую многие забывают.
Agile — это не Scrum.
Agile — это не набор митингов.
Agile — это не модный тренд.
Agile — это набор ценностей, ожиданий и дисциплин, которые помогают создавать качественные продукты в условиях постоянных изменений.
В основе Agile лежат четыре простые ценности:
смелость;
коммуникация;
обратная связь;
простота.
Именно вокруг них строятся все практики, которые появились позже.
Если коротко сформулировать главный вывод книги, то он звучит так: Agile — это не способ работать быстрее, Agile — это способ принимать более правильные решения и постоянно адаптироваться к изменениям, сохраняя качество продукта и прозрачность процесса. Именно поэтому спустя более двадцати лет после появления Agile многие его идеи остаются актуальными и сегодня.
Комментарии (5)

amaksr
30.05.2026 17:58Сам Боб Мартин, когда его прижали к стенке, где-то сказал, что Agile не единственно верная и не самая лучшая методология, и что он просто кричал про нее больше, чем другие про свои методологии. Поэтому если где-то кто-то не следует слепо Agile, это не значит что там процессы хуже. Скорее всего они лучше, так как адаптированы под конкретную ситуацию на земле. Но менеджеры любят Agile потому что это дает общепринятую структуру процесса, с одинаково трактуемыми терминами, и с однозначно определенными ролями и церемониями, что на всех проектах все выглядит единообразно. А проблем у Agile предостаточно.

SingleDigitIq
30.05.2026 17:58Мартин говорит на языке менеджмента, чтобы его услуги как консультанта можно было подороже продать, он осознал, что сегодняшний айти уже превращается в какой-то скам, половина стартапов, и вообще всё новое, обещает невозможное, и люди новые всему этому верят

SingleDigitIq
30.05.2026 17:58Мартин лично для меня морально устарел как только он написал книгу про чистый код.
Agile раньше был очень нужен, когда средний программист был задротом, не понимающим пользователя, требовался постоянный фидбэк от пользователя. Тогда веб 2 даже ещё толком не существовало, приложений настольных толком не было. А теперь веб 2 есть, и приложения есть, и огромный пласт статистических данных. То есть раньше разработка была альфой, а теперь стала бетой. В таком случае ориентироваться на фидбек, ждать его - это просто изнурять себя неопределённостью. Водопад на сегодняшний день просто лучше, что подтверждается опытом Японии, софт там до сих качественный, даже в эти годы, а не баг на баге, как во многих agile проектах, когда надо менять треть написанного кода, который по идее уже давно prod ready.
Тот, кто на сегодня, прибегает к методологии Agile, на самом деле не понимает до конца, что он пытается разрабатывать. А если чёткое понимание есть, то можно начать с чёткого плана waterfall. Или SAFe, что по сути тоже попытка уйти от хаоса agile к waterfall
WhiteLabelDevelopers
Agile уже лет 10 как не модный тренд, гибкие методологии это инструмент менеджмента поэтому они, априори, адресованы менеджерам. Очередная порция воды, на практике в России с процессами беда: все заучили пустые теоретические манифесты без малейшего понимания их внедрения на практике.
SingleDigitIq
Ну да. Agile делает всё обманчиво простым, как бы выражает какую-то суть действительности разработки формально. Получается, выглядит элегантно, хоть и сути не отражает, кого такая парадигма привлекает, смотрит на эту действительность в низком разрешении формального представления. Такая типичная ошибка присущая внезапно аутистам-аналитикам, которой подвержены также и менеджеры