Agile-манифест
Agile - это философия, основанная на Манифесте Agile, включающем в себя четыре ценности и двенадцать принципов.
11 февраля 2001 года в штате Юта семнадцать экспертов разработали Agile-манифест. Созданы четыре ценности и двенадцать принципов Agile.
Контекст создания
В конце 1990-х индустрия разработки ПО переживала кризис тяжеловесных процессов. Доминировали такие методологии, как RUP, DSDM и спиральная модель, которые требовали месяцев планирования и горы документации ещё до первой строки кода. Пузырь доткомов лопнул в 2000 году, и стало очевидно, что долгие циклы разработки не успевают за реальностью рынка.
Семнадцать практиков собрались на горнолыжном курорте Snowbird, чтобы найти общий знаменатель между лёгкими подходами к разработке. Среди подписантов манифеста:
- Kent Beck - создатель Extreme Programming (XP) и Test-Driven Development
- Martin Fowler - автор книг по рефакторингу и архитектуре
- Jeff Sutherland и Ken Schwaber - создатели Scrum
- Robert C. Martin (Uncle Bob) - автор принципов SOLID и концепции Clean Code
- Alistair Cockburn - автор семейства Crystal Methods
- Ward Cunningham - изобретатель вики и соавтор XP
- Andy Hunt и Dave Thomas - авторы “The Pragmatic Programmer”
Не новая методология, а набор ценностей
Авторы манифеста сознательно не создавали новый фреймворк. Они искали то общее, что объединяло XP, Scrum, Crystal, DSDM и другие лёгкие подходы. Результатом стал набор ценностей и принципов, а не набор практик.
Проблемы, которые они пытались решить:
- Проекты срывали сроки и бюджеты из-за негибких планов
- Заказчики получали продукт, который уже не соответствовал их потребностям
- Разработчики тонули в документации вместо создания работающего ПО
- Обратная связь приходила слишком поздно - на этапе финального тестирования
Ценности Agile
- Люди и взаимодействия важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Правая часть тоже имеет значение
Манифест не говорит, что процессы, документация, контракты и планы не нужны. Он утверждает, что левая часть каждого пункта ценнее правой. Это не бинарный выбор, а расстановка приоритетов.
Ценности на практике
Люди и взаимодействия важнее процессов и инструментов
Когда команда следует этой ценности: разработчик, столкнувшись с непонятным требованием, подходит к коллеге или заказчику и уточняет лично, вместо того чтобы писать формальный запрос через систему тикетов и ждать три дня ответа.
Когда команда игнорирует: любое общение между отделами проходит только через JIRA-тикеты с обязательным согласованием менеджера. Разработчик и тестировщик сидят в соседних кабинетах, но общаются через формальные баг-репорты с SLA на ответ.
Работающий продукт важнее исчерпывающей документации
Когда команда следует: каждые две недели заказчик видит работающий инкремент и может его потрогать. Документация пишется по необходимости - API-контракты, архитектурные решения, онбординг.
Когда команда игнорирует: команда три месяца пишет техническое задание на 200 страниц. За это время требования уже изменились, но документ ещё не согласован. Работающего кода нет.
Сотрудничество с заказчиком важнее согласования условий контракта
Когда команда следует: Product Owner еженедельно показывает прогресс стейкхолдерам. Если заказчик видит, что приоритеты изменились, команда перестраивает бэклог без формальной процедуры change request.
Когда команда игнорирует: заказчик хочет изменить приоритет фичи, но менеджер проекта требует оформить запрос на изменение, провести оценку влияния, согласовать новый бюджет. Процесс занимает две недели, за которые рыночная ситуация уже снова изменилась.
Готовность к изменениям важнее следования первоначальному плану
Когда команда следует: на ретроспективе выясняется, что текущий подход к деплою замедляет поставку. Команда выделяет время в следующем спринте на автоматизацию CI/CD, хотя этого не было в изначальном roadmap.
Когда команда игнорирует: команда продолжает реализовывать фичу, которая уже потеряла актуальность, потому что “она в плане на этот квартал” и менять план никто не готов.
12 принципов Agile
- Удовлетворение требований заказчика через раннюю и регулярную поставку продукта.
- Приветствие изменений требований, даже на поздних стадиях разработки.
- Частая поставка работающего продукта.
- Ежедневная работа разработчиков и бизнеса вместе.
- Поддержка мотивированных профессионалов.
- Непосредственное общение как эффективный способ обмена информацией.
- Работающий продукт как основной показатель прогресса.
- Поддержание устойчивого процесса разработки.
- Внимание к техническому совершенству и качеству.
- Простота и минимизация лишней работы.
- Развитие требований и решений через самоорганизующиеся команды.
- Регулярный анализ и улучшение эффективности.
Ключи к пониманию Agile
- Коммуникация - центральная роль общения и командного взаимодействия. Примерно 10% из 80-часового спринта отведено на общение разработчиков и менеджеров, чтобы понимать свои задачи. Очень важны фасилитация и коучинг коллег. Отвечает за принципы 4, 5, 6, 8, 11, 12.
- Эмпиризм - способность адаптироваться и изменять стратегию, основываясь на опыте. Отвечает за принципы 1, 2, 3, 4, 9, 12.
- Контроль качества - высокие стандарты качества и их поддержание. Отвечает за принципы 1, 4, 7.
Распространённые заблуждения
”Agile = нет документации”
Манифест говорит “работающий продукт важнее исчерпывающей документации”, а не “документация не нужна”. Ключевое слово здесь - исчерпывающей. Команде по-прежнему нужны API-документация, архитектурные решения (ADR), runbook-и для эксплуатации. Разница в том, что документация пишется по потребности и поддерживается актуальной, а не создаётся заранее “про запас” на сотни страниц.
”Agile = нет планирования”
Принцип “готовность к изменениям важнее следования плану” не означает отсутствие плана. Agile-команды планируют постоянно - на уровне спринта, релиза, квартала. Разница в том, что план рассматривается как гипотеза, а не как обязательство. Планирование происходит чаще и на более коротких горизонтах, что позволяет корректировать курс по мере поступления новой информации.
”Agile = хаос”
Самоорганизация не означает отсутствие структуры. Scrum, например, имеет чёткие роли (Product Owner, Scrum Master, Developers), определённые события (Sprint Planning, Daily, Review, Retrospective) и артефакты (Product Backlog, Sprint Backlog, Increment). Это не меньше структуры, чем в традиционных подходах - просто она другого характера. Команда сама решает, как выполнить работу, но рамки и ответственности чётко определены.
”Agile подходит всем”
Agile наиболее эффективен в условиях высокой неопределённости - когда требования нестабильны, рынок меняется, продукт инновационный. Для проектов с чёткими, неизменными требованиями, жёсткой регуляторной средой или критической безопасностью (авиация, медицинские устройства) более формализованные подходы могут быть уместнее. Модель Кеневин помогает определить, в какой области находится проект и какой подход к нему применить.
Agile - это не серебряная пуля
Слепое следование Agile-практикам без понимания ценностей приводит к тому, что Мартин Фаулер называет “flaccid Agile” - формально Agile, по сути хаос. Ценности первичны, практики вторичны.
Heart of Agile
В 2015 году Alistair Cockburn, один из подписантов оригинального манифеста, предложил упрощённую модель Heart of Agile как возврат к сути манифеста. После полутора десятилетий усложнения через тяжеловесные фреймворки масштабирования он свёл Agile к четырём действиям:
-
Collaborate
-
работайте
-
Deliver - поставляйте малыми порциями, получайте обратную связь как можно раньше
-
Reflect - регулярно останавливайтесь и анализируйте, что работает, а что нет
-
Improve - на основе рефлексии меняйте подход, инструменты, процессы
Эта модель не заменяет манифест, а дистиллирует его до самой сути. Если команда делает эти четыре вещи, она следует духу Agile независимо от того, какой конкретный фреймворк использует.
Agile - это не только инструменты и методологии, но и философия, основанная на гибкости, адаптации и тесном взаимодействии команды для достижения лучших результатов.