В какой сфере не будешь использовать Agile

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

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

1. Проекты с жёсткими физическими и регуляторными ограничениями (High-Cost-of-Change Projects)

Это строительство, аэрокосмическая отрасль, тяжёлое машиностроение, фармацевтика (разработка лекарств). Стоимость «обратной связи» и «итерации» здесь запредельна.

• Пример: Вы не можете каждый спринт «инкрементально» достраивать мост, меняя его архитектуру на основе отзывов пользователей. Нельзя выпустить «минимально работоспособный самолёт» (MVP) и затем дорабатывать его в полёте.
• Почему не Agile: В таких проектах 90% стоимости — это материалы и физические работы. Процесс требует предсказуемости, а не адаптивности. Методологии типа Waterfall (каскадная модель) или более современные Stage-Gate здесь незаменимы, так как требуют полного проектирования, расчётов и согласований ДО начала основных работ. Риск управляется не через быстрые эксперименты, а через тщательный upfront-анализ и прототипирование на ранних стадиях.

2. Критические системы безопасности и жизнеобеспечения

Атомная энергетика, медицинское оборудование для жизнеподдержания, системы управления полётами.

• Пример: Разработка программного обеспечения для кардиостимулятора. Требования к надёжности, безопасности и соответствию стандартам (например, IEC 62304 для медсофта) абсолютно незыблемы.
• Почему не Agile: Здесь доминирует парадигма V-модели (Verification & Validation), где каждому этапу проектирования строго соответствует этап тестирования. В Agile-подходе, где требования «вырастают» в процессе, обеспечить полную трассируемость (traceability) каждого требования через дизайн, код и тесты — невероятно сложно и дорого. Документация здесь не «рабочий артефакт», а юридически значимый документ для сертификации.

3. Проекты с фиксированным контрактом (Fixed-Price, Fixed-Scope)

Когда контракт с заказчиком или регулятором жёстко фиксирует бюджет, сроки и результат (Scope, Time, Cost — «железный треугольник»).

# Условная логика контракта, несовместимая с Agile
class FixedPriceContract:
    def __init__(self, scope, price, deadline):
        self.scope = scope  # Чёткий, подписанный список требований (SRS)
        self.price = price   # Фиксированная сумма
        self.deadline = deadline  # Жёсткая дата сдачи

    def deliver(self):
        # Сдача проекта = полное соответствие scope.
        # Изменение scope требует пересмотра контракта (Change Request).
        if self.actual_scope != self.original_scope:
            raise ContractViolationException("Изменение scope неприемлемо.")

• Почему не Agile: Суть Agile — в гибкости к изменениям требований. В фикс-прайс контракте такая гибкость юридически и финансово невозможна. Попытка внедрить Agile здесь приводит к конфликту: команда хочет адаптироваться, а заказчик справедливо требует полного соответствия подписанному ТЗ. Управление ведётся через детальное планирование (Critical Path Method) и строгий контроль изменений (Change Control Board).

4. Низкотехнологичные проекты с чёткой последовательностью

Монтаж инженерных сетей, некоторые виды ремонтных работ, организация массовых мероприятий по утверждённому регламенту.

• Почему не Agile: Процесс хорошо изучен, риски известны, оптимальная последовательность действий определена десятилетиями практики. Канбан может использоваться для визуализации потока задач, но полноценный Agile-цикл с ретроспективами и перепланированием бэклога избыточен. Здесь эффективнее классическое управление работами (task management).

Альтернативный подход: не «или-или», а гибрид (Hybrid)

Часто ситуация не чёрно-белая. Например, в разработке сложного медицинского прибора:

1. Аппаратная часть идёт по Stage-Gate (жесткий Waterfall).
2. Встроенное ПО (firmware) может использовать V-модель.
3. А сопутствующее мобильное приложение для врачей — идеальный кандидат для Scrum.

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