Внедрили Agile, проводите дейли и ретроспективы, делите работу на спринты — но результата нет. Пожары задач, техдолг растет, команды не успевают. В чем проблема? 

Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем. Разберемся, в чем настоящая проблема и как ее решить.

Agile стал ритуалом, а не инструментом

Компании применяют Agile формально — проводят дейли, ретроспективы и спринты для галочки, а не ориентируясь на цель.

Расскажу историю, которую услышал от коллеги. К его команде пришел заказчик с проектом на три месяца реализации. Заказчик сказал: «Отлично, теперь запустите его по Agile — нам нужен результат через месяц».

Многие считают Agile магическим словом, после которого все происходит быстрее. Это не так. Agile про другое: про адаптацию и обучение.

Та же история с мероприятиями. Возьмем дейли из Scrum — инструмент синхронизации команды, который помогает выявлять блокеры на пути к целям. По манифесту он занимает 15 минут. Я видел компании, где дейли растягивались на 30–40 минут, потому что каждый отчитывался по всем своим задачам. Никто не слушал друг друга — просто ждали своей очереди. Это не помогало команде работать, это создавало видимость контроля для менеджера.

— Dave Thomas, один из авторов Agile-манифеста, уже в 2014 году говорил, что Agile «умер», потому что превратился в набор ритуалов

История повторяется с планированием. Многие компании внедряют Scrum Poker, тратят время на оценку задач, но потом эти оценки нигде не используют. Зато красиво звучит: «Мы применяем Scrum Poker».

Именно поэтому появляются претензии: «Ваши гибкие методологии — это сплошные встречи». Давайте посчитаем: в двухнедельном спринте по Scrum 2 часа уходит на планирование, 1,5 часа на ретроспективу, и 2,5 часа на дейли по 15 минут каждый день. Итого: 6 часов за две недели. Относительно 80 рабочих часов это меньше 5% времени. Проблема не в количестве встреч — проблема в том, что их растягивают и не видят в них ценности.

Почему ИТ-команды страдают от неправильного Agile

Когда Agile применяют формально, процессы приводят не к гибкости, а к потере управляемости. Приведу несколько примеров из практики.

Команды реагируют на «пожары приоритетов»

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

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

Стремление уложиться в спринт порождает техдолг

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

— Исследования DevOps Research & Assessment (DORA) прямо показывают, что погоня за скоростью ухудшает качество, если жертвовать инженерными практиками

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

Метрики не отражают реальность

Velocity, количество закрытых задач — эти показатели не говорят о создании бизнес-ценности. Более того, когда метрики становятся KPI, команды начинают их «рисовать».

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

Таких примеров много. Как только метрики ставят в KPI или цели, они начинают рисоваться, а не отражать реальную картину мира.

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

Agile используют по кусочкам

Компании внедряют Agile фрагментарно — берут инструменты, но игнорируют принципы. В результате методологии не решают главную проблему: как создать единый поток разработки и поддержки продукта.

— Объединение команд разработки и технической поддержки: сквозные процессы ITSM в управлении разработкой

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

Главное, что большинство команд не понимают центральный принцип Agile: фокус важнее загруженности. Scrum требует решать одну задачу одновременно. Если три человека — аналитик, разработчик, тестировщик — работают над одной задачей, это быстрее, чем если они параллельно делают две задачи. Да, кто-то может простаивать. Но сама задача пройдёт по доске быстрее.

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

Вместо установки фокуса компании копируют внешние признаки методологий. Берут Kanban, делают 10 статусов с WIP-лимитом по 3–4 задачи на каждый — получается 30 задач в работе одновременно.

Доска выглядит «по-канбановски», но команда не становится быстрее — она постоянно переключается между задачами. Те, кто снижает WIP-лимиты до разумных значений, сразу видят результат: меньше задач на доске, но работа идёт быстрее.

Методологии недостаточно — нужна экосистема

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

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

Сделайте сквозную прослеживаемость от потребностей клиентов до релизов

Компании тратят силы на поиск очередного Scrum-мастера или delivery-менеджера, который будет проталкивать задачи через систему. Правильнее выстроить процессы так, чтобы вся команда участвовала в понимании потребностей клиентов и видела путь задачи до релиза.

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

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

Интегрируйте разработку и поддержку

Интеграция между системами управления сервисами (ITSM) и жизненным циклом разработки (SDLC) решает проблему сломанного телефона. Техдолг и обратная связь от пользователей должны автоматически попадать в бэклог команды.

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

— Практика Known Error Database (KEDB) и её примеры — ITIL wiki

Объединение ITSM-подходов с Agile позволяет использовать инструменты из обеих методологий. Например, KEDB для создания временных решений при критичных инцидентах и затем более прогнозируемого их решения с помощью Agile-методологии.

Опыт команды SimpleOne

Мы в компании пробовали много разных методологий. Начинали со Scrum, переходили к SAFe и в итоге пришли к Kanban.

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

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

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

Мы думаем не только о том, как управлять продуктом, но и о том, как взаимодействовать с другими отделами. Это и есть экосистема.

***

Сталкивались с ситуацией, когда команды начинали «рисовать» метрики ? Как решали эту проблему?