Agile — это не процесс. Это про то, почему ваш процесс не работает

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях и процессах, объясняет сложные концепции коротко и структурированно. Это видео — обзор Agile: не реклама и не критика, а попытка разобраться, чем Agile является на самом деле.

Большинство команд, которые «работают по Agile», работают по Scrum или Kanban — и это не одно и то же. Agile — это набор ценностей и принципов, сформулированных в Манифесте 2001 года. Он не описывает церемоний, ролей и спринтов. Scrum — это уже конкретный фреймворк, одна из возможных реализаций. Путаница между ними ведёт к тому, что команды «внедряют Agile» через ретроспективы и стендапы, не меняя при этом отношения к изменениям и клиенту — и потом удивляются, почему не работает.

Кому смотреть: разработчикам и тимлидам, которые участвуют в agile-церемониях, но не понимают, зачем они существуют. А также тем, кто слышит «мы agile-команда» и хочет проверить это утверждение на прочность.

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

Agile Manifesto — документ на одну страницу с четырьмя ценностями и двенадцатью принципами. Главная ценность звучит так: «Люди и взаимодействие важнее процессов и инструментов». Это звучит банально, но на практике большинство «agile-трансформаций» идут в обратном направлении: внедряют Jira, прописывают Definition of Done, назначают Scrum Master — то есть добавляют процессы и инструменты.

Видео разбирает разницу между Agile как философией, конкретными методологиями (Scrum, Kanban, XP) и фреймворками. Scrum — наиболее популярная реализация: спринты, Product Owner, ежедневные стендапы. Kanban — менее prescriptive: непрерывный поток задач, WIP-лимиты, фокус на времени цикла. Выбор зависит от характера работы, а не от моды.

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

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