Многие знают 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 многие его идеи остаются актуальными и сегодня.