Методологии разработки ПО: Agile, Scrum, Waterfall

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

Модель разработки (она же модель жизненного цикла) отвечает на вопрос «в каком порядке идут этапы». Строго по очереди и без возврата — это каскад. Циклами с повторами — итеративная. Модель ничего не говорит про митинги, роли и доски; она про форму траектории. Сами этапы — от аналитики до поддержки — мы разбирали в материале про жизненный цикл разработки ПО.

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

Фреймворк — конкретный каркас, который превращает философию в распорядок. Scrum и Kanban — фреймворки: они дают роли, события, артефакты и правила. Agile отвечает «почему гибко», Scrum — «как именно по вторникам».

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

Практический вывод для заказчика простой: когда подрядчик говорит «работаем по Agile», это ещё ничего не значит про сроки и цену. Спрашивайте на уровень ниже — какой фреймворк, какой ритм демонстраций, как фиксируется объём. Именно там, а не в красивом слове из договора, живёт ответ.

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

Waterfall (каскадная). Этапы идут строго друг за другом: требования → проектирование → разработка → тестирование → внедрение → поддержка. Следующий начинается, когда предыдущий полностью закрыт и подписан. Плюс — предсказуемость: объём, смета и срок известны на старте, документация исчерпывающая. Минус — негибкость: изменить требование на середине дорого, а работающий продукт заказчик видит только ближе к концу.

Каскад силён на проектах с зафиксированным и стабильным скоупом — госзаказ, тендер с ТЗ, интеграция по готовой спецификации, системы под сертификацию.

V-образная модель (V-model). Развитие каскада, где каждому этапу разработки заранее сопоставлен свой уровень тестирования: требованиям — приёмочные тесты, архитектуре — интеграционные, коду — модульные. Применяют там, где цена отказа критична: медтехника, транспорт, ПО безопасности.

Итеративная и инкрементная. Продукт делают не за один проход, а циклами. В итеративной модели каждый цикл улучшает уже существующую версию; в инкрементной — добавляет новый функциональный «кусок». Ошибки всплывают раньше, продукт можно показывать по частям. Это уже мостик к Agile — гибкие фреймворки, по сути, довели итеративность до предела.

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

В 2001 году семнадцать разработчиков собрались и сформулировали то, что назвали Agile Manifesto — Манифестом гибкой разработки ПО. Это не инструкция и не набор практик, а четыре ценности и двенадцать принципов о том, что в разработке важнее.

Четыре ценности звучат как пары «важнее, чем»:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования плану.

Ключевое слово — «важнее», а не «вместо». Документация, план и контракт никуда не деваются; просто когда они входят в противоречие с работающим продуктом и здравым смыслом, гибкий подход выбирает продукт. Отсюда вырастает вся механика: короткие циклы, ранние демо, готовность переставлять приоритеты, тесный контакт с заказчиком вместо переписки через юристов.

Важно не путать Agile с конкретным распорядком дня. Agile сам по себе не говорит, сколько длится итерация и кто ведёт планёрку, — это философия. Распорядок дают фреймворки. Самые распространённые — Scrum и Kanban.

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

Устройство Scrum держится на трёх опорах — роли, артефакты, события (описываем по действующему Scrum Guide 2020).

Роли. Product Owner — один человек (не комитет), отвечает за ценность продукта и порядок задач в бэклоге; именно он решает, что важнее. Scrum Master — отвечает за то, чтобы команда понимала и правильно применяла Scrum, снимает препятствия. Developers — кросс-функциональная команда, которая делает инкремент: разработчики, тестировщики, дизайнеры внутри одной команды.

Артефакты. Product Backlog — общий приоритизированный список всего, что нужно продукту. Sprint Backlog — то, что команда взяла в текущий спринт. Increment — результат спринта, соответствующий согласованному «определению готовности» (Definition of Done).

События. Sprint Planning — планирование, что берём в спринт. Daily Scrum — короткая (до 15 минут) ежедневная синхронизация команды. Sprint Review — демонстрация инкремента заказчику и сбор обратной связи. Sprint Retrospective — разбор, как улучшить сам процесс.

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

Kanban заходит с другой стороны. Здесь нет спринтов, нет обязательных ролей и фиксированных итераций — есть непрерывный поток задач и доска, на которой каждая задача движется по колонкам «в очереди → в работе → на проверке → готово».

Три вещи делают Kanban Kanban'ом. Визуализация — вся работа на виду, видно, где затор. Лимит незавершённой работы (WIP-лимит) — в каждой колонке не может одновременно висеть больше N задач; это заставляет доделывать начатое, а не хвататься за новое. Управление потоком — команда следит за временем прохождения задачи и расшивает узкие места.

Kanban силён там, где работа приходит потоком и приоритеты меняются в реальном времени: поддержка и сопровождение, поток мелких доработок, служба эксплуатации. Задачу можно добавить или переставить в любой момент — не нужно ждать конца спринта.

Три названия, которые постоянно встречаются в перечислениях, но редко объясняются.

XP (Extreme Programming, экстремальное программирование) — не про распорядок, а про инженерную дисциплину: парное программирование, разработка через тесты (TDD), непрерывная интеграция, частые релизы. XP отлично уживается со Scrum: Scrum отвечает за организацию, XP — за качество кода внутри.

Lean (бережливая разработка) — перенос идей бережливого производства в софт: убирать всё, что не создаёт ценности, сокращать потери, ускорять поток. Скорее образ мышления, чем фреймворк; Kanban во многом вырос из Lean.

RAD (Rapid Application Development) — быстрая разработка на прототипах с активным вовлечением пользователя, когда важно как можно раньше получить работающую версию и дошлифовать её по обратной связи. Идеологически близок к идее MVP.

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

Water-Scrum-Fall. Самый частый гибрид на подрядных проектах. Старт — по Waterfall: собрали требования, зафиксировали общий объём и бюджет, подписали договор. Сама разработка — по Scrum: спринты, демо, гибкая приоритизация внутри согласованного скоупа. Финал — снова каскадный: контролируемый релиз, приёмка, передача в эксплуатацию.

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

Scrumban. Гибрид Scrum и Kanban: берём роли и события Scrum, накладываем сверху канбан-доску и WIP-лимиты. Удобно командам, которые уходят от жёстких спринтов к потоку, и особенно — на этапе поддержки, когда продукт уже запущен и работа превращается в поток доработок.

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

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

SAFe (Scaled Agile Framework) — самый распространённый: набор практик, который выстраивает Agile на уровне всей компании, с единым ритмом планирования для десятков команд. Тяжеловесный, но управляемый.

LeSS (Large-Scale Scrum) — более лёгкая альтернатива, которая старается остаться максимально близко к чистому Scrum, просто растянув его на несколько команд одного продукта.

Для среднего бизнеса и большинства заказных проектов это избыточно — тема актуальна, когда счёт команд идёт на десятки. Упоминаем, чтобы картина была полной.

Универсально «лучшей» методологии нет — есть подходящая конкретной задаче. Отталкиваться стоит от двух вопросов: насколько чётко зафиксированы требования и насколько важна ранняя обратная связь.

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

Fixed Price и Waterfall — родственники. Фиксированная цена возможна там, где объём заранее зафиксирован: подрядчик может посчитать смету, потому что знает, что именно делает. Это каскадная логика. Плюс для заказчика — понятно, сколько заплатишь, риск перерасхода на стороне исполнителя. Минус — любое изменение требований идёт через допсоглашение, а не через «по-быстрому подкинем ещё фич».

Time & Materials и Agile — тоже родственники. Почасовая оплата естественна для гибкой разработки: объём подвижен, платишь за фактическое время команды. Плюс — максимальная гибкость, можно менять курс каждый спринт. Минус — итоговая сумма заранее неизвестна, и контроль за расходами полностью на заказчике.

Выбирать методологию по моде, а не по проекту. «Все делают Scrum, значит и нам надо» — так фиксированный тендерный проект с готовым ТЗ загоняют в спринты, теряя предсказуемость и не приобретая гибкости. Методология подбирается под задачу и способ оплаты, а не наоборот.

Называть Scrum'ом то, что им не является. Ежедневные созвоны без инкремента, спринты без демо, бэклог без владельца — это карго-культ, а не гибкость. Половина разочарований в Agile — это разочарование в его имитации.

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