Agile-манифест: ценности и принципы, а не набор ритуалов

Есть простая диагностическая процедура. Придите в команду, которая «работает по Agile», и спросите: «Что вы сделаете, если через две недели после старта спринта станет ясно, что пользователю нужна другая фича?» Если ответ звучит как «ну, спринт же уже запланирован, добавим в следующий» — команда делает ритуалы. Если ответ звучит как «мы поговорим с Product Owner, оценим, стоит ли эта информация отмены Sprint Goal, и решим» — команда делает Agile.

Разница не в дисциплине и не в старательности. Разница в том, понимает ли команда, зачем существуют её практики. Scrum-мастер, который знает механику событий Scrum, но не знает, из какой философии они выросли, будет защищать форму и терять суть: следить, чтобы дейли укладывался в 15 минут, и не замечать, что на нём никто ни с кем не разговаривает.

Эта статья — про фундамент. Мы разберём Agile-манифест не как исторический памятник, а как набор инженерных решений: каждая ценность отвечала на конкретный способ провалить проект, распространённый в конце 1990-х. Многие из этих способов провалить проект живы и сейчас.

Зачем это на PSM I. Экзамен Scrum.org проверяет прежде всего Scrum Guide, но вопросов «в духе манифеста» там достаточно: про реакцию на изменения, про роль документации, про самоуправление. Scrum — это один из способов реализовать agile-мышление, и большинство неверных ответов на экзамене неверны именно потому, что противоречат ценностям, а не букве.

Откуда манифест взялся: предыстория, которую обычно пропускают

Февраль 2001 года, горнолыжный курорт Snowbird, штат Юта. Семнадцать человек — авторы и практики разных «лёгких» методологий — три дня спорят и в итоге подписывают документ из 68 слов в основной части. Это Manifesto for Agile Software Development (есть официальный русский перевод), плюс двенадцать принципов.

Важно понимать, что они не изобретали итеративность. К 2001 году за плечами было:

• 1970, Уинстон Ройс, «Managing the Development of Large Software Systems». Знаменитая ирония истории: статью считают манифестом «водопада», хотя Ройс на второй же странице пишет, что чистая последовательная модель «рискованна и напрашивается на провал», и предлагает итерации и прототип. Индустрия скопировала первую картинку и проигнорировала текст. PDF первоисточника.
• 1986, Такеути и Нонака, «The New New Product Development Game» (Harvard Business Review). Оттуда пришла метафора регби-схватки — scrum — как способ описать кросс-функциональные команды, которые двигают продукт «всей кучей», а не эстафетой.
• 1990-е: набор «лёгких методологий» — Scrum (Швабер и Сазерленд, первая публичная презентация 1995), Extreme Programming (Кент Бек), Crystal (Алистер Кокбёрн), DSDM, Feature-Driven Development, Adaptive Software Development.

Все эти методы существовали параллельно и назывались «lightweight». В Snowbird семнадцать человек искали общее слово и общий знаменатель. Слово нашли — agile, «гибкий, поворотливый». Общий знаменатель оформили в четыре ценности.

Четыре ценности: не «вместо», а «важнее»

Формулировка манифеста устроена как перевес, а не как отрицание. Оригинал заканчивается фразой: «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева». Это самая часто игнорируемая строчка документа.

Разберём каждую пару по схеме: какую боль она лечила → что ломается, если ценность игнорировать → как её извращают на практике.

1. Люди и взаимодействие важнее процессов и инструментов

Боль. В конце 1990-х господствовала идея, что качество продукта — функция качества процесса. Отсюда тяжёлые модели зрелости, регламенты на сотни страниц и вера, что правильно настроенный процесс сделает результат предсказуемым независимо от людей. На практике получалось наоборот: сильные инженеры уходили из-за бюрократии, а оставшиеся честно следовали процессу и производили посредственность.

Что ломается без этой ценности. Появляется «процесс как алиби»: решение принято не потому, что оно верное, а потому что «так написано в регламенте». Команда перестаёт думать. Классический симптом — конфликт разрешается эскалацией в трекер, а не пятиминутным разговором.

Как извращают. Два зеркальных перекоса:

• «Процессы не нужны вообще» — так не стоит. Манифест не отрицает процесс, он отрицает примат процесса. Scrum сам по себе процессный каркас; без него взаимодействие вырождается в хаос.
• «Мы купили Jira, теперь у нас Agile» — подмена взаимодействия инструментом. Если статус задачи в трекере — единственный способ узнать, что происходит, ценность нарушена, даже если все церемонии проводятся по расписанию.

Сценарий для Scrum-мастера. Два разработчика третий день спорят в комментариях к тикету, тон становится ядовитым, задача не двигается. Плохой ход: написать третий комментарий с призывом к порядку. Хороший ход: увести обсуждение в живой разговор (звонок, доска) с чётким вопросом «какое решение мы принимаем и по какому критерию», а потом зафиксировать итог в тикете одной строкой. Инструмент остаётся хранилищем решения, но не местом его принятия.

2. Работающий продукт важнее исчерпывающей документации

Боль. Проекты, где полгода писали спецификацию, согласовывали её, а первую работающую сборку заказчик видел на десятом месяце — и она была не тем, что нужно. Документ давал иллюзию прогресса: 400 страниц выглядят как работа, хотя ценность для пользователя равна нулю.

Что ломается без этой ценности. Теряется единственный честный индикатор прогресса. Пока софт не работает, любая оценка «готовности» — это мнение. Отсюда классические «90% готово» на протяжении трёх месяцев.

Как извращают. «Agile — это когда мы не пишем документацию». Так не стоит: манифест говорит про исчерпывающую (comprehensive) документацию, то есть про попытку описать всё заранее и полностью. Runbook на инцидент, ADR с обоснованием архитектурного решения, схема интеграции для смежной команды — это документация, которая сама по себе является рабочим продуктом. Отказ от неё — не гибкость, а технический долг.

Хороший практический критерий: документ оправдан, если у него есть конкретный читатель в конкретной ситуации. «Спецификация, потому что положено» — нет. «Описание контракта API, потому что три команды на него завязаны» — да.

3. Сотрудничество с заказчиком важнее согласования условий контракта

Боль. Модель fixed-price/fixed-scope, где заказчик и подрядчик после подписания становятся противниками. Заказчик выжимает максимум из формулировок, подрядчик защищается change request’ами. Обе стороны заняты контрактом, а не продуктом.

Что ломается без этой ценности. Изменение требований превращается во взаимное обвинение вместо совместного решения. Заказчик перестаёт делиться реальным контекстом, потому что любое слово может быть использовано против него.

Как извращают. «Раз мы гибкие, контракт не нужен». Так не стоит — деньги и обязательства существуют. Гибкость реализуется через форму контракта: оплата за время и материалы с фиксированным ритмом поставки, контракты с переменным объёмом при фиксированном бюджете, «money for nothing, change for free» Джеффа Сазерленда. Практическую сторону мы разбираем в статье про риски трека project-management: Управление рисками.

Сценарий. Заказчик на Sprint Review говорит: «Это не то, что я имел в виду». Плохой ход Scrum-мастера — открыть тикет и доказать, что acceptance criteria выполнены. Формально вы правы, стратегически проиграли. Хороший ход — принять сигнал как ценную информацию (мы дёшево узнали о расхождении), выяснить, какое допущение оказалось неверным, и вместе с Product Owner решить, что с этим делает бэклог.

4. Готовность к изменениям важнее следования первоначальному плану

Боль. План, зафиксированный в момент максимального незнания. Требования замораживались тогда, когда о продукте и пользователях известно меньше всего, и дальше вся система защищала это раннее решение.

Что ломается без этой ценности. Команда строит то, что перестало быть нужным, и называет это успехом, потому что уложилась в план. Это самый дорогой вид провала: он выглядит как победа в отчётности.

Логика картинки: в длинном цикле цена изменения растёт экспоненциально, потому что каждое поздно обнаруженное расхождение тянет за собой уже сделанную работу. Итеративная поставка не отменяет рост стоимости, но держит его почти плоским за счёт коротких петель обратной связи и технических практик (тесты, непрерывная интеграция, рефакторинг). Без инженерных практик кривая итеративной команды выгибается вверх точно так же — это важный нюанс, который редко проговаривают.

Как извращают. «Мы гибкие, поэтому планировать не надо». Так не стоит. Манифест противопоставляет готовность к изменениям следованию плану, а не планированию как деятельности. Дуайт Эйзенхауэр сформулировал точно: «Планы бесполезны, но планирование незаменимо». В Scrum планирование происходит постоянно — Sprint Planning, уточнение бэклога, ежедневная перепланировка на Daily Scrum.

Двенадцать принципов: как ценности превращаются в поведение

Ценности абстрактны, принципы конкретнее. Их удобно держать в голове не списком из двенадцати пунктов, а четырьмя смысловыми кластерами.

Пройдёмся по нетривиальным.

«Наивысшим приоритетом является удовлетворение заказчика за счёт ранней и непрерывной поставки ценного ПО». Слово ценного делает всю работу. Поставка ради поставки — это тоже провал, просто быстрый. Отсюда, кстати, растёт Product Goal в Scrum Guide 2020.

«Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения конкурентного преимущества заказчика». Обратите внимание на глагол: не «терпим», а «приветствуем», и не ради комфорта, а ради преимущества. Если конкурент не может изменить курс, а вы можете — это стратегический актив.

«Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев». В 2001 году «пара недель» была радикальной. Сейчас команды с непрерывной поставкой релизят десятки раз в день — и это не отклонение от манифеста, а его логическое продолжение. Как измерять эту способность объективно, разбирается в статье DORA и инженерные метрики.

«Простота — искусство минимизации лишней работы — крайне необходима». Единственный принцип, который прямо разрешает не делать. На практике это самый сложный принцип для команды под давлением: гораздо легче добавить фичу, чем защитить решение её не строить.

«Лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд». Здесь корень того, что в Scrum Guide 2020 называется self-managing: команда сама решает кто и как делает работу. Заметьте: манифест приписывает самоорганизации не только процесс, но и архитектуру. Это прямой аргумент против «архитектор рисует, команда кодирует».

«Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта». Причинно-следственная связь идёт от качества к гибкости, а не наоборот. Команда с гнилой кодовой базой физически не может быть гибкой: любое изменение дорого. Именно этот принцип чаще всего выбрасывают первым, а потом удивляются, что через год спринты не помогают. Про то, как это удерживать инструментально, — Качество и поставка.

Где рвётся связь: от ценности к ритуалу и обратно

Карго-культ возникает не потому, что люди глупые. Он возникает потому, что практику скопировать легко, а её обоснование — нет. Цепочка от ценности до конкретного действия длинная, и рвётся она в предсказуемых местах.

Работа Scrum-мастера в значительной степени состоит в том, чтобы находить эти обрывы. Не «проводятся ли ретроспективы», а «меняется ли что-нибудь после ретроспектив». Не «есть ли Definition of Done», а «останавливает ли он выпуск недоделанного».

Полезная диагностическая рамка — разложить практики команды по двум осям: насколько формально практика соблюдается и насколько она реально даёт эффект.

Четвёртый квадрант — то, куда уходит большая часть энергии организаций, «внедривших Agile». Именно там живут зомби-скрам и мини-водопад; подробный разбор — в статье Антипаттерны Scrum.

Манифест и Scrum: как они соотносятся

Частая путаница у новичков: «Agile» и «Scrum» используются как синонимы. Это неверно и на экзамене наказывается.

Scrum Guide прямо говорит: Scrum основан на эмпиризме и бережливом мышлении (lean thinking), а его элементы неделимы — «Scrum’s … elements … are immutable», и реализация лишь части не даёт Scrum. При этом Scrum Guide не ссылается на Agile-манифест как на источник правил. Это два разных документа, и на экзамене вопросы про Scrum надо решать по Scrum Guide.

На практике большинство организаций приходит в Scrum, уже произнеся слово «Agile», и Scrum-мастеру приходится объяснять разницу примерно раз в квартал. Полезная формулировка: «Agile — это про то, во что мы верим. Scrum — это про то, как мы устроим следующие две недели, чтобы проверить, работает ли наша вера».

Отдельно стоит держать в голове пять ценностей Scrum — Commitment, Focus, Openness, Respect, Courage (приверженность, фокус, открытость, уважение, смелость). Они появились в Scrum Guide и не тождественны ценностям манифеста, но выражают ту же философию на уровне поведения команды. Подробно — в следующей статье трека.

Три реалистичных сценария

Сценарий 1. «Изменения запрещены до конца квартала». Директор по продукту объявляет: бэклог зафиксирован на квартал, потому что «постоянные метания мешают команде». В этом есть здравое зерно — хаотичные приоритеты действительно убивают производительность.

Что делает Scrum-мастер. Не спорит про манифест. Разделяет два разных явления: фокус внутри спринта (полезен, и Scrum Guide его защищает: Sprint Goal не меняется в ходе спринта) и заморозку бэклога на квартал (вредна, потому что убивает петлю обратной связи). Предложение: границу фиксации сдвинуть со квартала на спринт, а на квартал фиксировать не список задач, а цель продукта. Это даёт руководителю ту стабильность, которую он на самом деле хотел, не убивая адаптивность.

Сценарий 2. «Дейли — это отчёт для меня». Руководитель разработки ходит на Daily Scrum и слушает, кто чем занят. Разработчики говорят в его сторону, а не друг с другом.

Что делает Scrum-мастер. Атака в лоб («вам сюда нельзя») портит отношения. Работающий путь — выяснить потребность: скорее всего, ему нужна прозрачность, и он не знает другого способа её получить. Дать альтернативу (доступ к доске, приглашение на Sprint Review, короткий еженедельный разговор), затем договориться о смене формата дейли: разработчики планируют день друг для друга, руководитель — гость без права голоса. Ценность «люди и взаимодействие» реализуется не запретом, а восстановлением настоящего адресата разговора.

Сценарий 3. «Мы напишем тесты потом». Команда под дедлайном режет технические практики. Через три спринта скорость падает вдвое, багов — втрое.

Что делает Scrum-мастер. Не читает лекцию про принцип технического совершенства. Делает эффект видимым: на ретроспективе показывает динамику доли времени на исправление дефектов, соотносит с моментом отказа от тестов. Дальше это разговор Product Owner и Developers про Definition of Done — Scrum-мастер не решает за них, но обеспечивает, чтобы решение принималось с данными, а не по ощущениям. Про метрики и их злоупотребления — в статье Эмпиризм и метрики.

Вопросы в формате PSM I

Экзаменационные вопросы Scrum.org коварны не сложностью, а точностью формулировок. Тренируйтесь замечать слова «всегда», «должен», «кто отвечает».

Вопрос 1. Agile-манифест утверждает, что документация не имеет ценности. Верно или неверно?

• A. Верно
• B. Неверно

Вопрос 2. Согласно принципам Agile, как часто следует поставлять работающий продукт?

• A. В конце проекта
• B. С периодичностью от пары недель до пары месяцев, отдавая предпочтение меньшему сроку
• C. Каждый день
• D. Когда заказчик попросит

Вопрос 3. Команда на десятый день двухнедельного спринта узнаёт от пользователей, что одна из запланированных функций бесполезна. Что должно произойти?

• A. Команда доделывает функцию, потому что она в Sprint Backlog
• B. Scrum-мастер отменяет спринт
• C. Developers и Product Owner обсуждают влияние на Sprint Goal и корректируют Sprint Backlog
• D. Изменение вносится в следующий спринт, текущий не трогают

Вопрос 4. Кто отвечает за то, чтобы команда следовала ценностям Agile-манифеста?

• A. Scrum-мастер
• B. Product Owner
• C. Вся Scrum-команда
• D. Менеджмент организации

Вопрос 5. Какие два утверждения о самоорганизующихся командах верны? (выберите два)

• A. Команда сама решает, кто выполняет какую работу
• B. Команда сама выбирает Product Owner
• C. Команда сама решает, как превратить элементы бэклога в инкремент
• D. Команда сама определяет порядок элементов в Product Backlog

Типичные ошибки начинающего Scrum-мастера

• Цитировать манифест в споре. «Но в манифесте написано» — аргумент нулевой силы. Работают наблюдаемые последствия: сколько времени тратится на переделки, как быстро команда узнаёт о своей ошибке.
• Путать гибкость с отсутствием обязательств. Agile не означает «сроков нет». Он означает, что при фиксированном времени договариваться можно об объёме, и делать это явно, а не молча срывая дедлайн.
• Считать манифест священным текстом. Документу больше двух десятилетий, часть контекста устарела: он написан про проекты и заказчиков, а не про продуктовые команды и непрерывную поставку. Некоторые из подписантов сами критиковали то, во что превратилась индустрия вокруг слова «Agile» — стоит прочитать эссе Дейва Томаса «Agile is Dead» и заметку Мартина Фаулера «The State of Agile Software in 2018» про «Agile Industrial Complex».
• Игнорировать инженерную часть. Манифест написан программистами про программирование. Без тестов, CI и рефакторинга гибкость невозможна физически — этот пробел частично закрывает Manifesto for Software Craftsmanship (2009).

Мини-итог

• Манифест — это четыре перевеса и двенадцать принципов, а не запреты. Формулировка «не отрицая важности того, что справа» — ключ ко всему документу и к половине экзаменационных вопросов.
• Каждая ценность лечила конкретную болезнь конца 1990-х: примат процесса, документацию вместо продукта, контрактную войну, замороженные требования. Болезни живы.
• Принципы удобно держать четырьмя кластерами: ценность для клиента, отношение к изменениям, люди и коммуникация, устойчивость и качество.
• Гибкость невозможна без технического качества: причинная связь идёт от качества кода к способности менять курс, а не наоборот.
• Agile ≠ Scrum. Манифест — мышление, Scrum — фреймворк с неизменяемыми элементами. На PSM I вопросы про Scrum решаются по Scrum Guide.
• Работа Scrum-мастера — восстанавливать оборванную связь между практикой и её смыслом. Не «проводится ли ретро», а «меняется ли что-то после него».

Что дальше

Мы разобрали философию. Теперь пора к тексту, который на экзамене является единственным источником истины: Scrum Guide построчно: что там написано на самом деле — пройдём документ по разделам, отделим определения от рекомендаций и разберём места, где формулировка 2020 года отличается от того, что «все знают».

Источники

• Manifesto for Agile Software Development и Двенадцать принципов — первоисточник, официальный русский перевод
• The Scrum Guide — актуальная редакция, обязательное чтение для PSM I
• Winston Royce, «Managing the Development of Large Software Systems», 1970
• Takeuchi, Nonaka, «The New New Product Development Game», HBR, 1986
• Kent Beck, «Extreme Programming Explained: Embrace Change», 2nd ed., Addison-Wesley, 2004
• Martin Fowler, «The New Methodology» — лучший разбор того, чем «лёгкие» методы отличались от тяжёлых
• Manifesto for Software Craftsmanship, 2009