Перейти к основному контенту
Tech Path Finder
КурсыИнтервьюКод-ревьюБлог
Tech Path Finder

Персонализированный путеводитель в IT. Квизы, мок-интервью, код ревью и аналитика прогресса.

@potapov_me

Платформа

  • Курсы
  • Прогресс
  • Мок-интервью
  • Код ревью
  • Живое ревью с ИИ
  • Тренажёр переговоров
  • Закладки

Контент

  • Блог
  • Главная
  • Обратная связь

Компания

  • О проекте
  • Тарифы
  • Условия использования
  • Конфиденциальность
  • Согласие на обработку данных
  • Cookie
  • Реквизиты

Аккаунт

  • Войти
  • Зарегистрироваться
  • Профиль

© 2026 Tech Path Finder. Все права защищены.

·ИП Потапов К.С.·Политика конфиденциальности·
Сделано с ❤️ в России
  1. Agile Anti-patterns
anti_patterns

Agile Anti-patterns

ScrumBut, cargo cult, zombie agile, dark scrum

Учебник: Анти-паттерны Agile

Время освоения: ~40 минут
Цель: Научиться распознавать и преодолевать распространенные анти-паттерны в Agile-практиках


#Быстрый справочник

#10 анти-паттернов: диагностика и лечение

Анти-паттернСимптомРешение
ScrumBut"Мы Scrum, но без ретро / PO / SM"Вернуться к Scrum Guide, понять зачем каждый элемент
Zombie AgileРитуалы есть, ценности нетИзмерять бизнес-результаты, работать с реальными пользователями
Cargo CultКопируют практики без понимания "зачем"Задавать вопрос "зачем?" к каждой практике
Dark ScrumScrum = инструмент контроля, штрафы за % выполненияПерейти от контроля к доверию и договорённостям
МикроменеджментМенеджер назначает задачи каждому разработчикуДелегировать, коучить, а не управлять
Перегрузка спринтаКаждый спринт берут 130–150% от velocityИспользовать velocity как ориентир, фокус на качестве
Бумажный ScrumДокументы есть, практики нетУпростить документацию, фокус на работающих процессах
Нет Product OwnerПриоритеты определяются голосованиемНазначить PO, дать ему полномочия
Agile TheaterВнешняя демонстрация Agile без измененийВвести измеримые метрики, психологическую безопасность
Техдолг как нормаПостоянное откладывание рефакторингаТехдолг в бэклог, выделять время каждый спринт

#Как распознать анти-паттерн

ВопросЕсли ответ "да" → проблема
Проводим церемонии, но ничего не меняется?Zombie Agile / Agile Theater
Менеджер решает, кто что делает?Микроменеджмент / Dark Scrum
"Мы делаем это, потому что так принято"?Cargo Cult
Спринт не выполняем третий раз подряд?Перегрузка / нет refinement
PO не участвует в работе команды?Нет Product Owner

#Введение (5 минут)

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

Ключевые принципы для распознавания анти-паттернов:

  • Фокус на процессах вместо результатов
  • Отсутствие адаптации к контексту команды
  • Использование Agile как инструмент контроля, а не улучшения
  • Формальное выполнение ритуалов без понимания их цели

💡 Помните: Agile — это не набор правил, а система ценностей и принципов. Анти-паттерны возникают, когда мы забываем о ценностях и фокусируемся только на процессах.


#Основные анти-паттерны (25 минут)

#1. ScrumBut ("Мы используем Scrum, но...")

Описание: Когда команда говорит "мы используем Scrum, но..." и нарушает основные принципы.

Примеры:

  • "Мы используем Scrum, но у нас нет Product Owner"
  • "Мы используем Scrum, но не проводим ретроспективы"
  • "Мы используем Scrum, но менеджер назначает задачи"

Признаки:

  • Отсутствие одной из трех ролей Scrum (PO, SM, Dev Team)
  • Нарушение церемоний или артефактов
  • Формальное следование процессу без понимания цели

Решение: Вернуться к основам Scrum Guide, сфокусироваться на ценностях, а не на процессах.


#2. Зомби-агайл (Zombie Agile)

Описание: Команда формально следует процессам (спринты, стендапы), но без понимания ценностей Agile.

Примеры:

  • Спринты проходят, но нет реальной работы над ценностью для пользователя
  • Ретроспективы проводятся, но никто не выполняет действия
  • Стендапы превратились в отчет перед менеджером

Признаки:

  • Низкая гибкость при изменении требований
  • Отсутствие обратной связи от заказчиков
  • Команда работает по плану, а не по ценности

Решение: Ввести практики, фокусирующиеся на ценности: регулярная демонстрация результатов, работа с реальными пользователями, измерение бизнес-результатов.


#3. Культ груза (Cargo Cult)

Описание: Копирование практик без понимания их цели и контекста применения.

История: Во время Второй мировой войны на Тихоокеанских островах местные жители строили деревянные самолёты, чтобы вызвать настоящие самолёты с грузом.

Примеры:

  • Проведение ретроспективы, но игнорирование действий
  • Использование Jira без понимания, зачем нужны story points
  • Спринты по 2 недели, но без адаптации к контексту проекта

Признаки:

  • "Мы делаем так, потому что так принято"
  • Отсутствие вопросов "зачем?" и "для чего?"
  • Копирование практик из других компаний без анализа контекста

Решение: Внедрять эксперименты, задавать вопросы "зачем?", фокусироваться на результатах, а не на процессах.


#4. Тёмный скрам (Dark Scrum)

Описание: Когда Scrum используется как инструмент контроля, а не для улучшения работы команды.

Примеры:

  • Менеджер требует 100% выполнения спринта
  • Наказание за недостаточное выполнение
  • Спринт-план как жесткий контракт, а не договоренность

Признаки:

  • Давление на выполнение плана
  • Отсутствие рефлексии и улучшений
  • Команда боится говорить о проблемах

Решение: Перейти от контроля к доверию, использовать Sprint Commitment как договоренность, а не контракт, фокусироваться на улучшении процесса.


#5. Микроменеджмент в Agile

Описание: Менеджер контролирует каждую задачу и принимает решения вместо команды.

Примеры:

  • Менеджер назначает задачи каждому разработчику
  • Проверка каждого шага разработки
  • Принятие решений без участия команды

Признаки:

  • Нарушение принципа самоорганизации
  • Команда не берет на себя ответственность
  • Низкая вовлеченность и инициативность

Решение: Делегировать ответственность, обучать команду принятию решений, использовать коучинг вместо управления.


#6. Перегрузка бэклога спринта

Описание: Команда берёт больше задач, чем может выполнить, что приводит к нехватке времени и снижению качества.

Примеры:

  • Берут 20 задач вместо 10 из-за давления менеджера
  • "Давайте возьмём ещё пару задач, они же простые"
  • Игнорирование истории скорости (velocity)

Признаки:

  • Регулярное невыполнение спринта
  • Снижение качества кода
  • Откладывание задач до следующего спринта

Решение: Использовать историю скорости для планирования, фокусироваться на качестве, а не количестве, вводить ограничения WIP.


#7. Бумажный скрам (Paper Scrum)

Описание: Процессы документируются, но не применяются на практике.

Примеры:

  • Есть подробные руководства по Scrum, но команда работает по waterfall
  • Описанные церемонии не проводятся в реальности
  • Документация существует, но не используется

Признаки:

  • Разрыв между документацией и практикой
  • Команда не знает деталей процессов
  • Отсутствие живого бэклога

Решение: Упростить документацию, фокусироваться на практике, вводить изменения постепенно через эксперименты.


#8. Отсутствие Product Owner

Описание: Команда сама определяет приоритеты без четкого владельца продукта.

Примеры:

  • Приоритеты определяются голосованием в команде
  • PO отсутствует или выполняет роль техлида
  • Нет единого лица, ответственного за содержимое бэклога

Признаки:

  • Конфликты приоритетов между задачами
  • Потеря фокуса на ценности для пользователя
  • Низкая скорость доставки ценности

Решение: Назначить ответственного PO, обучить его роли, обеспечить доступ к заинтересованным сторонам.


#9. Агайл-обман (Agile Theater)

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

Примеры:

  • Спринты и ретроспективы проводятся, но ничего не меняется
  • Использование терминов Agile без понимания их смысла
  • Демонстрация процессов для руководства, а не для улучшения

Признаки:

  • Внешняя демонстрация Agile без внутренних изменений
  • Отсутствие измеримых улучшений
  • Команда говорит "мы Agile", но работает по старым методам

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


#10. Технический долг как норма

Описание: Команда систематически откладывает рефакторинг и исправление технического долга.

Примеры:

  • "Сейчас нет времени на рефакторинг, сделаем потом"
  • Технический долг не отслеживается в бэклоге
  • Новые функции добавляются поверх старого кода

Признаки:

  • Замедление разработки со временем
  • Рост количества багов
  • Трудности с внедрением новых функций

Решение: Видимость технического долга в бэклоге, выделение времени на рефакторинг, использование метрик (cycle time, lead time).


#Чеклист для аудита команды

Используйте эти вопросы раз в квартал для диагностики анти-паттернов. Каждый «да» — сигнал для разговора:

Красный флагВозможный анти-паттерн
SM назначает задачи разработчикам напрямуюМикроменеджмент
Ретроспективы проводятся, но ничего не меняетсяZombie Agile / Agile Theater
«У нас Scrum, но без PO / без ретро / без ревью»ScrumBut
Sprint = жёсткий контракт, штрафы за недовыполнениеDark Scrum
«Мы делаем так, потому что так принято»Cargo Cult
Технический долг никогда не попадает в бэклогТехнический долг как норма
Спринты идут, но пользователи не получают ценностьБумажный Scrum / Zombie Agile
Команда боится говорить о проблемах на ретроDark Scrum / нет психологической безопасности
Приоритеты меняются каждый день по запросу менеджераНет Product Owner / нет стратегии
Каждый спринт берут в 1,5 раза больше velocityПерегрузка спринта

#Практические упражнения (10 минут)

#Упражнение 1: Распознавание анти-паттернов

Определите, какой анти-паттерн описан в каждом случае:

  1. Команда проводит ретроспективу каждый спринт, но никогда не выполняет предложенные действия.
  2. Менеджер требует, чтобы команда выполнила 100% задач спринта, иначе будет штраф.
  3. В бэклоге 500 задач, и команда не может приоритизировать их.
  4. PO отсутствует, и приоритеты определяются голосованием в команде.
  5. Команда использует Jira, но не понимает, зачем нужны story points.

Ответы:

  1. Agile Theater / Zombie Agile
  2. Dark Scrum
  3. Перегрузка бэклога
  4. Отсутствие Product Owner
  5. Cargo Cult

#Упражнение 2: Решение проблем

Для каждой ситуации предложите решение:

  1. Команда берёт слишком много задач в спринт и не успевает их выполнить.
  2. Ретроспективы проходят, но никто не выполняет действия.
  3. Технический долг растёт, и разработка замедляется.

Решения:

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

Далее: Agile Coaching