— Хватит, — сказал он, — низкопоклонства перед Западом. Мы русские люди. Какой еще, к лешему, «Скрам»? Какое «Велью»? С понедельника живем по правде.

Так в нашем опенспейсе наступило средневековье.

В понедельник мы собрались на PI-планирование. Теперь это называлось «Великий Сход». Атмосфера была тревожная. Программисты, люди по природе своей циничные и ленивые, жались к стенам.

В центр зала вышел наш Release Train Engineer, Аркадий. Раньше он носил худи с логотипом React, теперь на нем была льняная рубаха, правда, поверх джинсов. Глаза его горели нездоровым огнем.

— Братья! — возопил Аркадий. — Гой еси, мастеровые! Собрались мы ныне, дабы снарядить Обоз Поставки в путь долгий, на квартал грядущий!

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

— Староста, — поправил я его шепотом. — Ты теперь не тимлид, а Староста Артели «Бэкенд».

— Я идиот, — буркнул Леха. — А Аркаша — Голова Обоза. Звучит как диагноз.

Началось все с «Оглашения Замысла». Вышли Попечители (бывшие стейкхолдеры) и полчаса рассказывали, как важно нам захватить рынок доставки собачьего корма. Потом слово взял Град-Зодчий (в девичестве — Enterprise Architect). Он развернул схему микросервисов, похожую на карту взятия Казани, и велел строить хоромы каменные, чтоб на века.

Нас разгнали по углам — на «Артельные Посиделки».

— Так, — сказал Леха, глядя в джиру. — У нас тут Затея висит. «Интеграция с платежным шлюзом». Как оценивать будем?

— В стори-поинтах нельзя, — напомнил я. — Соловейчик велел в Вершках. Или в Пядях.

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

— Много, — возразил тестировщик Гриша. — Не сдюжим. У нас Тяга слабая, половина артели в отпусках.

— Ладно, пиши пять вершков. И пусть Господь управит.

Самое страшное началось у Доски Пути. Это была огромная пробка на стене, вся опутанная красными нитками. Аркадий бегал вдоль нее, спотыкаясь о провода, и кричал:

— Чьи Путы?! Кто кого держит? Почему Артель «Фронтенд» не может начать верстать кнопку?

— Дык, — отозвался с галерки фронтендер, — мы ждем, пока бэкендеры базу окучат.

— Путы! — трагически воскликнул Голова Обоза. — Тугие, окаянные путы! Староста Леха, пошто задерживаешь братьев своих?

Леха молчал. Ему хотелось курить и, возможно, убить Аркадия.

К вечеру перешли к «Укрощению Лиха». Это был ритуал ROAM, только с национальным колоритом.

— Лихо первое! — зачитывал Аркадий. — «Сервер падает при нагрузке в тысячу юзеров». Кто возьмет на душу?

— Я возьму, — вздохнул Град-Зодчий. — Буду Опекуном сего Лиха.

— Добро! Лихо второе! «Дизайнер уходит в декрет».

— Тут мы бессильны, — сказали из зала.

— Значит, — Аркадий развел руками, — на все воля Божья. Принимаем как есть. Accepted. То есть, тьфу, «Смирение».

В финале было голосование. «Пятерня Веры». Нужно было поднять руку и показать пальцами, верим ли мы в успех нашего безнадежного Обоза.

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

Но он был Старостой. У него была ипотека и двое детей.

— Голосуем! — взревел Голова Обоза.

В воздух взмыли десятки рук. Все показывали открытую ладонь. Пять перстов. Полная вера. Зуб даем, всё исполним.

— Любо! — прослезился Аркадий. — Сдюжим, православные! Трогай Обоз!

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

— Пять вершков, — задумчиво сказал Леха, глядя на огонек сигареты. — А ведь не сдюжим.

— Не сдюжим, — согласился я. — Зато как звучит! Не факап, а «Лихо». Не баг, а «Испытание». Чувствуешь величие?

— Чувствую, — сказал он. — Пойдем, Радетель. Нам еще код писать. Или, как теперь говорят, бересту марать.

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

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

Раздел I. О Людях и Чинах

• Agile Team — Артель.

  Боевая единица производства. Группа людей, объединенных общей бедой и сроками. Живут в одной избе (или чате), делят радости и баги.

• Scrum Master — Староста.

  Человек, который не пашет, не сеет, а только спрашивает: «Что ты делал вчера, мил человек, и что будешь делать сегодня?». Следит, чтобы в Артели не пили медовуху до релиза.

• Product Owner — Радетель (Хозяин изделия).

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

• Release Train Engineer (RTE) — Голова Обоза.

  Главный погонщик. Человек с самым громким голосом и самыми расшатанными нервами. Отвечает за то, чтобы все телеги ехали в одну сторону, даже если лошади сдохли.

• System Architect — Главный Зодчий.

  Старец, рисующий на бересте красивые схемы, которые невозможно воплотить в жизнь. Живет в башне из слоновой кости (или в отдельном кабинете).

• Developers — Мастеровые.

  Трудовая кость. Люди, которые своими руками превращают безумные фантазии Радетелей в работающий (иногда) код.

Раздел II. О Деяниях и Обрядах

• PI Planning — Великий Сход.

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

• Team Breakouts — Артельные Посиделки.

  Время, когда Мастеровые запираются в углах и пытаются понять, как впихнуть невпихуемое в отведенные сроки.

• Confidence Vote — Пятерня Веры (Рукоприкладство).

  Обряд всеобщего поручительства. Поднятая рука с пятью пальцами означает: «Зуб даю, сделаем». Один палец (особенно средний) показывать не рекомендуется во избежание гнева Попечителей.

• ROAM — Укрощение Лиха.

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

  1. Избыто (R) — проблему решили (спрятали под ковер).

  2. Взято на душу (O) — нашли крайнего.

  3. На всё воля Божья (A) — смирились с неизбежным крахом.

  4. Соломка подстелена (M) — придумали оправдание заранее.

Раздел III. О Мерах и Вещах

• Feature — Затея.

  Крупная хотелка Попечителей. Обычно формулируется как «Хочу, чтоб было красиво и само работало».

• User Story — Поделка.

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

• Story Points — Вершки (или Пяди).

  Мера сложности, понятная только самим Мастеровым. Один вершок — работа легкая. Восемь вершков — без пол-литры не разобраться.

• Dependency — Путы.

  То, что мешает жить. Красные нити на Скрижали Пути, символизирующие, что одна Артель ждет, пока другая перестанет лениться.

• Capacity — Тяга.

  Сила лошадиная. Способность Артели тащить воз. Обычно переоценивается в два раза в начале пути и недооценивается в конце.

• Program Board — Скрижаль Пути.

  Доска позора и надежды. На ней видно, кто работает, а кто создает Путы.

Другие подобные рассказы можно прочитать тут https://dovlatov-ai.web.app/

Строительство: много материальных затрат на этапе производства

В строительстве классическое распределение затрат выглядит так:

• Проектирование: 5-10% от общей стоимости

• Материалы: 50-60%

• Строительно-монтажные работы: 30-40%

• Пуско-наладка и сдача: 5-10%

Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.

Машиностроение: баланс между разработкой и производством

Машиностроение занимает промежуточное положение:

• НИОКР и проектирование: 20-30%

• Создание прототипов и испытания: 15-25%

• Освоение производства (оснастка, станки, линии): 30-40%

• Серийное производство: 10-20% на единицу продукции

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

IT-разработка: "бесплатное" тиражирование

В IT-разработке принципиально иное распределение:

• Проектирование и анализ: 30-40%

• Разработка: 40-50%

• Тестирование и внедрение: 20-30%

• Поддержка и развитие: 15-25% годовых от стоимости разработки

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

Почему в IT можно начинать с весьма "сырого" продукта?

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

В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.

Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.

Это возможно благодаря:

1. Нулевой стоимости копирования - можно создать сотню экспериментальных версий без финансовых потерь

2. Модульной архитектуре - компоненты можно заменять независимо друг от друга

3. Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени

Стоимостные риски и их управление

Строительство: страхование через детализацию

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

• 80-90% рисков управляются на этапе проектирования

• Используются детальные 3D-модели и BIM-технологии

• Предусматриваются запасы прочности в конструкциях

• Стоимость изменений после начала строительства кратно превышает стоимость проектирования

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

Машиностроение: управление через прототипирование

В машиностроении риски распределены между разработкой и производством:

• Создаются физические прототипы для проверки концепций

• Проводятся ресурсные испытания в экстремальных условиях

• Используются CAD/CAM системы для виртуального моделирования

• Освоение производства идет поэтапно с постоянной доработкой

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

Разработка ПО: управление через итерации

В программировании и разработке ПО риски управляются иначе:

• Риск несоответствия требованиям минимизируется через постоянную обратную связь

• Технические риски снижаются через рефакторинг и технический долг

• Рыночные риски управляются через A/B тестирование и постепенный rollout

• Безопасность обеспечивается через непрерывное тестирование и обновления

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

Практические примеры от нейросети Qwen

Строительство: Burj Khalifa
Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.

Машиностроение: Tesla Model 3
Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.

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

Почему аналогии вредны в проектном управлении и как найти баланс

Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.

практические советы для IT проектов:

1. Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857

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

3. Управление техническим долгом - регулярный рефакторинг - это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.

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

Вывод

Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.

Этот переезд называется SAFe (Scaled Agile Framework).

Если Scrum — это джаз-банд в прокуренном кабаке, где трое играют, а один фальшивит, то SAFe — это симфонический оркестр государственной филармонии. Музыкантов сотня, дирижеров пятеро, ноты утверждены в министерстве, и импровизация карается расстрелом (или увольнением, что при ипотеке одно и то же).

Вот как устроен этот колосс.

1. Метафора: Поезд, идущий в никуда (Agile Release Train)

В Scrum была команда. В SAFe придумали ART (Agile Release Train) — Поезд Релиза.

Это не просто метафора, это диагноз. Представьте себе состав, в который загнали 5–10 команд (человек 100–120). Все они должны ехать в одну сторону и с одной скоростью.

• Если одна команда (вагон) сойдет с рельсов — под откос летит весь состав.

• Остановить поезд нельзя. Он едет по расписанию, которое называется Program Increment (PI).

• Обычно этот PI длится 8–12 недель. Это время, за которое поезд должен доехать от станции «Мы ничего не понимаем» до станции «Вроде работает, но трогать страшно».

2. Главный спектакль: PI Planning

Раз в два-три месяца случается событие, по масштабу сравнимое с первомайской демонстрацией. Называется PI Planning.

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

• Суть ритуала: Команды пытаются угадать, что они будут делать следующие три месяца.

• Доска зависимостей (Program Board): Это такой алтарь SAFe. На стену вешают ватман, лепят стикеры и соединяют их красными нитками.

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

Задача мероприятия — убедить руководство, что красные нитки не затянутся у нас на шее.

3. Новые персонажи (Роли)

В Scrum было трое. В SAFe, как в бюрократическом аппарате, количество начальников растет в геометрической прогрессии.

1. RTE (Release Train Engineer).

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

2. Product Management (Управление Продуктом).

   Один Владелец Продукта (PO) уже не справляется. Появляется целая каста менеджеров. Они решают, куда едет поезд. Простые смертные разработчики их видят редко, как небожителей.

3. System Architect (Системный Архитектор).

   Человек, который знает, как в теории всё это должно работать. Он рисует красивые схемы облаков и микросервисов. Когда схемы сталкиваются с реальностью (легаси-кодом 1998 года), Архитектор обычно грустит или говорит: «Это детали реализации».

4. Уровни (Levels)

SAFe любит иерархию.

• Team Level (Уровень команды): Тут всё по-старому. Сидят ребята, пишут код, ругаются на дейли. Их жизнь почти не меняется, только давления больше.

• Program Level: Тут живут менеджеры среднего звена и RTE. Тут решают судьбы фич.

• Portfolio Level (Портфель): Самый верх. Там сидят люди в дорогих костюмах и делят бюджеты. Слов «рефакторинг» и «технический долг» там не знают. Там знают слова «Стратегические Темы» и «ROI».

5. Инновации и Планирование (IP Iteration)

В конце каждого квартала есть специальная итерация — IP (Innovation and Planning).

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

В реальности (как и в Советском Союзе) в это время мы в мыле доделываем то, что не успели за предыдущие два месяца. «Инновация» заключается в том, чтобы придумать, как сдать сырой проект и не покраснеть.

Вместо морали

SAFe — это попытка натянуть уютный свитер Agile на слона корпорации. Свитер трещит, слону неудобно, но выглядит солидно.

Если вам говорят: «У нас SAFe», знайте: будет много встреч, много красивых слов, красных ниток и длинных таблиц в Excel. Но в глубине, под толщей этой бюрократии, всё так же сидит одинокий программист, который просто хочет, чтобы его код скомпилировался без ошибок.

И в этом, пожалуй, есть какая-то надежда.

Другие подобные рассказы тут https://dovlatov-ai.web.app/

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

Вот как это выглядит изнутри.

Действующие лица

В этой пьесе три роли. И, как водится, согласия между ними нет.

1. Владелец Продукта (Product Owner). Человек с фантазией. Он знает, что мы делаем, но понятия не имеет, как. Его задача — хотеть. Хотеть много, сразу и желательно вчера. Он приносит список требований, который деликатно называют Бэклогом, хотя правильнее было бы назвать его «Списком несбыточных надежд».

2. Скрам-мастер. Это не начальник. Начальников мы не любим. Это, скорее, массовик-затейник с грустными глазами. Он следит за тем, чтобы ритуал соблюдался. Чтобы никто никого не убил во время спора. Он убирает препятствия. Например, если у программиста закончился кофе или вера в человечество, Скрам-мастер должен это исправить.

3. Команда (Developers). Люди, которые работают. Молчаливые, угрюмые профессионалы. Они превращают фантазии Владельца в суровую реальность кода. Их задача — сделать так, чтобы оно заработало, и уйти домой вовремя (что почти никогда не удается).

Метафизика оценки: Часы и Сторипоинты

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

Поэтому придумали Story Points (SP). Это такие условные «попугаи».

• Суть: Мы не говорим: «Я буду делать это два дня». Мы говорим: «Эта задача тянет на 5 попугаев».

• Почему так? Потому что человек слаб и со временем у него сложные отношения. А вот сравнивать он умеет. Сказать, что одна задача в два раза гаже другой — это мы можем.

• Числа: Используют числа Фибоначчи: 1, 2, 3, 5, 8, 13... Почему их? Чтобы жизнь медом не казалась.

  • 1-3 SP: Ерунда. Дело на перекур.

  • 8 SP: Придется попотеть. Возможно, пожертвовать выходным.

  • 13 SP: Это уже не задача, это эпопея. Ее нужно рубить на куски, иначе она раздавит вас своим величием.

Часы мы оставляем для интимных подробностей. Когда спринт уже начался, и вы наедине с собой планируете день — тогда считайте часы. Но заказчику про часы ни слова. Он все равно переведет их в деньги и расстроится.

Ритуалы (Events)

Жизнь в Scrum делится на отрезки — Спринты. Обычно это две недели. Две недели надежды, завершающиеся неизбежным дедлайном.

1. Планирование (Planning). Собираемся и играем в покер. Серьезно. Называется Planning Poker. Берем задачу. Каждый кидает карту с цифрой (те самые попугаи). Если у одного «3», а у другого «13» — начинается беседа. Один утверждает, что там работы на час, другой — что там надо переписывать вседро. Истина, как обычно, где-то посередине, но ближе к пессимизму.

2. Ежедневный Скрам (Daily). Пятнадцать минут позора каждое утро. Стоя. Говорим три вещи:

   • Что я сделал вчера (обычно — меньше, чем хотел).

   • Что сделаю сегодня (обычно — больше, чем смогу).

   • Что мне мешает (обычно — всё).

3. Обзор (Review). Конец спринта. Показываем, что наработали. Важно: показывать надо работающую вещь, а не презентацию. Заказчик тыкает кнопки, хмурится или радуется. Мы стоим, потеем и ждем вердикта.

4. Ретроспектива. Самое русское мероприятие. Сидим, говорим о судьбе. Вопрос «Кто виноват?» стараемся не задавать. Задаем вопрос «Что делать?». Решаем, как в следующем спринте жить лучше. Обычно решаем меньше курить и писать чистый код. В следующем спринте, конечно, все повторяется, но сам разговор имеет терапевтический эффект.

Вместо эпилога

Есть такое понятие — Velocity (Скорость). Это сколько «попугаев» команда умудряется прожевать за спринт. Сначала цифра скачет, как курс валют. Потом стабилизируется.

Главное в этом деле — Definition of Done (Критерий Готовности). Договоритесь на берегу: что значит «Сделано». «Сделано» — это не «я написал, вроде компилируется». «Сделано» — это «проверено, протестировано, залито, и за это не стыдно».

Вот, собственно, и весь Scrum. Система простая, как граненый стакан, и такая же необходимая для душевного равновесия в коллективе

Другие подобные статьи тут https://dovlatov-ai.web.app/

Agile — это ценности, а не методология

Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:

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

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

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

   Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.

Waterfall: миф о жестком подходе

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

Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)

5. Внедрение (Подготовка и передача программы)

Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:

1. Устранение ошибок.

2. Развитие и усовершенствование продукта.

Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.

Почему возникает миф о несовместимости?

Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».

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

Однако в реальности:

Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками.
Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum.
Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.

Синтез вместо конфронтации: гибридные подходы

На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например:
Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.

Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.

Как же выбирать методологию? Нужно опираться на критерии, а не догмы
Выбор между Waterfall и итерационными методами зависит от четырёх факторов:

1. Предсказуемость требований.
   Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.

2. Стоимость изменений.
   В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.

3. Регуляторные ограничения.
   В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.

4. Культура команды и заказчика.
   Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.

Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum

Заключение: за пределами маркетинговых мифов

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

1. Какова степень неопределённости требований?

2. Какие ограничения накладывают регуляторы или бюджет?

3. Насколько команда и заказчик готовы к гибкости?

Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:

1. Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».

2. Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).

3. Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.

Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.