Привет, Хабр! Меня зовут Иван, я руководитель отдела тестирования фронт-офисных и интеграционных систем в РГС.

В этой статье я хочу посмотреть на ключевые ценности Agile не сквозь розовые очки, а через призму управленческой практики. Разобрать, как они на самом деле работают, где помогают, где ломаются и что с этим делать тем, кто отвечает за результат.

Agile без мифов и романтики

Agile давно превратился из методологии в модный корпоративный аксессуар. Где-то он появляется по необходимости, а где-то по принципу «все побежали, и я побежал». В одних компаниях его внедряют с горящими глазами, в других — так же стремительно откатываются обратно в Waterfall, едва столкнувшись с кризисом или очередной нестабильностью рынка.

Парадокс заключается в том, что именно Agile идеально подходит для работы в условиях высокой неопределенности и кризисов:

1. Быстрая обратная связь и короткие циклы разработки: возможность быстро пересматривать приоритеты на уровне спринта и/или чаще, что в условиях кризиса необходимо для выживания.

2. Фокусировка на ценности: в условиях ограниченных ресурсов, критически важно делать только то, что приносит максимальную ценность здесь и сейчас, а не тратить полгода на докручивание продукта до идеала, который завтра может стать ненужным [пример: фичи корпоративного ПО, разработанные «в стол», по причине изменения регуляторки, а следовательно, и нормативных актов].

3. Кросс-функциональные команды: их преимущество — возможность быстро перестраивать процессы, находить обходные пути, не дожидаясь распоряжений из десяти разных отделов.

Чаще всего причина провалов проста: отсутствие зрелости, непонимание сути методологии и попытка заменить мышление церемониями. Мы механически проводим дейлики, участвуем в ретроспективах «для галочки» [ведь это же бесполезное занятие, правда?] и искренне удивляемся, почему команда продолжает тонуть в бюрократии, заказчик недоволен, а любые изменения воспринимаются не как норма развития продукта, а как локальная катастрофа.

Четыре ключевые ценности Agile: где они работают, а где ломаются

Agile начинается с ключевых ценностей — это фундамент, на котором зиждется вся методология. Чистая эмпирика.

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

В теории ключевые ценности звучат очевидно и банально, но это обманчивая простота. В условиях отсутствия компетенций и должного уровня зрелости они ломаются о реальность и не оправдывают ожиданий. Однако, когда мы применяем их через призму рационального менеджмента и накопленных знаний об управлении системами, они раскрываются во всей красе.

Давайте разбираться.

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

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

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

Где ломается:

• Начинаем «чинить процесс», а не решать проблему;

• Оперативную коммуникацию заменяем переписками в почте и регламентами;

• Каждая сторона пытается доказать, что права, вместо того чтобы сделать работу.

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

В условиях высокой динамики изменений чрезмерная детализация документации не просто не добавляет ценности — она губительна. Зрелый подход и рациональная работа заключаются в поиске достаточного (на уровне MVP), а потом уже оптимального (с учетом заданных критериев и всех факторов) уровня формализации.

Документация нужна как инструмент коммуникации и фиксации текущего состояния, но не как «священный грааль», которому нужно слепо следовать, игнорируя реальность и тем самым взращивая технический долг. Изменчивость современного рынка — да что там рынка, современной жизни! — кричит нам о том, что адаптивность системы к внешней среде — вопрос выживания.

Где ломается:

• Стремление к излишней детализации съедает сроки;

• Документация становится самоцелью;

• Боязнь ранних релизов и негативной обратной связи.

Принцип №3: Сотрудничество с заказчиком важнее согласования условий контракта

В классическом (водопадном) подходе отношения строятся на жестком контракте, который подписывают «на берегу». Заказчик хочет получить максимум ценности за минимум стоимости, исполнитель — минимизировать риски и зафиксировать объем работ (Fix Price vs T&M).

В такой парадигме заказчик и исполнитель находятся по разные стороны баррикад, потому что:

• для заказчика: любая доработка = угроза бюджету;

• для исполнителя: любая ошибка = претензия;

• для обеих сторон: любое изменение требований = изменение условий контракта.

Данный принцип призывает заменить антагонистическую модель отношений между заказчиком и исполнителем на партнерскую, потому что настоящая ценность создается в процессе живого, доверительного взаимодействия, а не в многочасовых юридических баталиях и формальном исполнении пунктов контракта.

Заказчик вовлекается в процесс разработки: помогает приоритизировать бэклог задач, дает конструктивную обратную связь, объясняет бизнес-контекст, а исполнитель становится партнером по решению бизнес-задач.

Где ломается:

• Заказчика воспринимают как источник требований, а не как партнера;

• Любые изменения (требований, объема работ и т.д.) проходят через изменение условий контракта — это тормозит разработку продукта;

• Сотрудничество заменяют формализмами и бюрократией.

Принцип №4: Готовность к изменениям важнее следования плану

В условиях VUCA-мира [VUCA — это акроним для описания современного мира и бизнес-среды как Volatility (Изменчивость), Uncertainty (Неопределенность), Complexity (Сложность) и Ambiguity (Неоднозначность)] попытка "идти по плану до конца" гарантированно провалится, столкнувшись с реальностью.

План нужен и важен как инструмент коммуникации и целеполагания на старте. Это не догма. Рациональный подход заключается в том, чтобы воспринимать план как гипотезу, которую нужно регулярно проверять и адаптировать.

Где ломается:

• План становится догмой;

• Изменения во внешней среде вызывают сопротивление вместо адаптации;

• Команда теряется при любом отклонении от курса, не умеет пересматривать приоритеты.

Принцип разумной достаточности и допустимый риск как общий знаменатель ценностей Agile

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

Разумная достаточность по сути и есть фундамент зрелого Agile: делать достаточно хорошо, чтобы приносить ценность сейчас, и достаточно гибко, чтобы не тормозить изменения завтра.

Суть принципа:

Экономическая целесообразность: нет смысла тратить миллионы на защиту от угрозы, которая может принести ущерб в несколько тысяч.

Оптимизация: поиск не идеального, а достаточно хорошего решения, которое обеспечивает требуемый уровень результата при рациональном использовании ресурсов (времени, денег, усилий).

Гибкость: уровень требований может снижаться или повышаться в зависимости от контекста и реальных условий.

Допустимый риск (или приемлемый риск) — это уровень риска, с которым общество, организация или отдельный человек готовы мириться ради получения определенных положительных результатов или выгод от деятельности. Этот риск считается оправданным с учетом экономических, социальных и экологических факторов.

Суть концепции:

Риск никогда не бывает нулевым: полное устранение всех рисков невозможно или нерационально.

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

Обоснование: уровень риска должен быть оправдан (например, выгодой от инновационного проекта или использованием современных технологий).

Таким образом, эти два принципа являются универсальными инструментами мышления, которые помогают реализовать ключевые ценностные ориентиры Agile-манифеста на практике.

Четыре ключевые ценности Agile не стоит воспринимать как противопоставление левой части манифеста правой. Это рациональная приоритезация производственного процесса:

Не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

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

Фактически 4 базовые ценности Agile — это компас, который подсказывает команде: «при столкновении с неопределенностью — выбирайте то, что приближает вас к ценности, а не к формализации».