Модели разработки: от Waterfall к Agile

← назад к разделу

Когда над продуктом работает больше одного человека, появляется вопрос: в каком порядке всё делать? Сначала собрать все требования или начать кодить сразу? Тестировать в конце или на каждом шаге? Показывать заказчику готовое или промежуточное? Ответы на эти вопросы и есть модель разработки — договорённость о том, как команда движется от идеи к работающему продукту.

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

Зачем вообще модель процесса

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

Модель процесса отвечает на три практических вопроса:

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

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

Waterfall: этапы строго по порядку

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

1. Сбор и фиксация требований.
2. Проектирование (архитектура, дизайн).
3. Разработка (написание кода).
4. Тестирование.
5. Поставка и сопровождение.

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

Любопытно, что автора у этой модели, по сути, нет. Схему из фаз подряд первым нарисовал Уинстон Ройс в статье 1970 года — и тут же написал, что в таком виде она рискованна и напрашивается на провал, а делать надо как минимум дважды: сначала черновой прототип, потом настоящую систему. Слова «waterfall» у него в статье нет вообще: название приклеилось позже, а предостережение по дороге потерялось.

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

И вот где Waterfall ломается: ошибка, допущенная на этапе требований, обнаруживается только на этапе тестирования — через месяцы. К этому моменту на неверном фундаменте уже построены проектирование и весь код. Исправление дорого не само по себе: правку приходится тащить обратно через дизайн и весь уже написанный код. По классическим замерам Барри Боэма выходило, что поздняя правка дороже ранней в десятки раз; сам множитель с тех пор много раз оспаривали и на современных проектах он не воспроизводится, но направление осталось — чем позже нашли, тем дороже. Продукт целиком собирается только в самом конце — и до этого момента никто не видел, работает ли он вообще.

V-модель: тестирование привязано к каждому этапу

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

Смысл в том, что о тестировании думают заранее, вместе с проектированием. Планируя требования, вы сразу описываете, как будете проверять, что они выполнены. Это заставляет формулировать требования проверяемо и ловить часть ошибок раньше — на бумаге, а не в готовом продукте.

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

Главное следствие V-модели: проверку пишут вместе с требованием

У V-модели есть практический вывод, который переживает саму модель и работает в любом процессе: приёмочная проверка формулируется в тот же момент, что требование, а не после реализации.

Механика простая. Записали требование — тут же отвечаете на вопрос «как мы проверим, что оно выполнено». Не можете ответить — требование сформулировано плохо, и это видно сразу, а не через три месяца на приёмке.

Пример того, как это меняет формулировку:

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

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

Итеративная и инкрементальная разработка: не всё сразу

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

Здесь стоит различать два близких слова:

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

Разницу проще запомнить на одной задаче — сделать поиск по каталогу.

Инкрементально (растём по кусочкам, каждый готов):

1. Поиск по точному названию товара. Работает, можно отдать пользователям.
2. Добавили поиск по описанию. Та же простая механика, новый кусок.
3. Добавили фильтр по цене. Ещё кусок.

Итеративно (возвращаемся к тому же и улучшаем):

1. Поиск по точному совпадению названия. Работает плохо, но работает.
2. Тот же поиск, но с учётом словоформ («кроссовки» находят «кроссовок»).
3. Тот же поиск, но с учётом опечаток и с ранжированием по популярности.

Обратите внимание: в первом случае растёт набор возможностей, во втором — качество одной возможности. Практическое следствие важнее определений: инкремент можно остановить в любой момент и получить меньший, но осмысленный продукт; итерацию остановить нельзя — поиск с опечатками недоделанным быть не может, он либо ищет приемлемо, либо нет.

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

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

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

Agile: не метод, а набор ценностей

Спорят «у нас Scrum или Agile?» — вопрос бессмысленный, и вот почему. Agile — это не методология и не набор инструкций. Это набор ценностей, зафиксированный в 2001 году в документе под названием Agile Manifesto. Его подписали разработчики, уставшие от тяжёлых плановых процессов, и сформулировали, что для них важнее.

Манифест построен как четыре противопоставления «важнее — чем»:

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

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

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

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

• Scrum — работа короткими фиксированными отрезками (sprint), роли, регулярные встречи, backlog задач.
• Kanban — визуализация потока задач на доске и ограничение числа задач в работе (WIP-лимит).
• Extreme Programming (XP) — набор инженерных практик: парное программирование, тесты вперёд кода, частые релизы.

Все они — способы воплотить одни и те же ценности разными наборами практик. Поэтому спорить «Scrum или Agile» бессмысленно: Scrum и есть один из способов быть Agile.

Как выбирать модель под задачу

Главная ошибка — считать, что есть «правильная» модель, а остальные устарели. Нет. Каждая решает свою задачу, и выбор зависит от двух вопросов: насколько стабильны требования и как дорого обходятся изменения.

Ориентир простой:

• Требования жёсткие, зафиксированы, есть регуляторика и ответственность за жизнь и деньги (медтех, авиация, банковское ядро, госстандарты) — плановые модели (Waterfall, V-модель). Здесь ценна предсказуемость и полный след документации, а изменения по ходу редки и дороги в любом случае.
• Требования неопределённые, продукт новый, важна частая обратная связь от пользователей (стартап, новый цифровой продукт, исследовательская задача) — Agile-подходы. Здесь способность быстро менять курс важнее детального плана на год вперёд.

Где гибкий подход ломается

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

Нет доступа к заказчику. Весь механизм держится на короткой обратной связи: показали — услышали — поправили. Если решение принимает комиссия, собирающаяся раз в квартал, обратной связи нет, и итерации превращаются в двухнедельные отчёты. Что делают: либо добиваются представителя заказчика с правом решать (это условие, а не пожелание), либо признают, что работают по плановой модели, и планируют честно.

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

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

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

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

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

Как смешивают на практике

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

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

Фиксируем срок, торгуемся объёмом. Дата выпуска жёсткая (распродажа, регуляторный срок, договор), а состав гибкий: есть обязательная часть и список того, что войдёт, если успеем. Это самая честная и самая рабочая комбинация: она даёт заказчику предсказуемость по дате, а команде — возможность не врать про объём. Требует одного: приоритеты расставлены заранее и явно, иначе в последнюю неделю резать будут по случайному признаку.

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

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

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

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

Глубже: спираль Боэма и RUP: итерация вокруг рисковрасширенное

Между V-моделью и итерациями статья перепрыгивает через модель, в которой итерация впервые построена не вокруг функций, а вокруг рисков, и без неё непонятно, откуда у итеративной разработки вырос порядок.

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

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

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

Глубже: договор решает модель: фиксированный объём против оплаты по временирасширенное

«Стабильные требования или нет» это половина ответа на вопрос, почему одни проекты идут водопадом, а другие спринтами. Вторая половина в договоре: кто платит и за что.

Фиксированный объём и цена. Заказчик платит за описанный результат, и подписанное техническое задание это единственная защита обеих сторон: исполнителя от «мы имели в виду другое», заказчика от «это не входило». Отсюда водопад по форме: требования зафиксированы до начала, изменение это дополнительное соглашение с ценой и сроком, а приёмка это сверка с ТЗ. Гибкость здесь не ценность, а риск для исполнителя, и он закладывает её в цену запасом. Так работают тендеры, государственные заказы и всё, где деньги выделены заранее.

Оплата по времени. Заказчик платит за часы или за спринты команды, а объём определяет по ходу; исполнитель не рискует объёмом, заказчик не рискует переплатить за ненужное, если следит. Здесь спринты естественны: приоритеты меняются каждые две недели без соглашений, а защита заказчика это прозрачность (что сделано за деньги) и право остановить в любой момент. Требует доверия и вовлечённости заказчика, которых на старте отношений нет.

Смешанные формы. Фиксированная цена за первую фазу (проработка и каркас) и оплата по времени дальше; оплата по времени с потолком; фиксированные спринты с переменным содержанием. Внутренняя разработка в компании это оплата по времени по определению, и поэтому там спринты; подрядчик по тендеру это фиксированный объём, и поэтому там ТЗ, даже если внутри команда живёт итерациями.

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

Глубже: после выпуска: дежурство, инцидент и разбор без виноватыхрасширенное

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

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

Инцидент. Процедура записана заранее: кто объявляет инцидент, где идёт общение, кто ведёт хронологию, как принимают решение об откате, кому сообщают. Во время инцидента чинят, а не выясняют; сначала вернуть работу (откат), потом причину.

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

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

Коротко

• Модель разработки — договорённость о порядке шагов и о том, когда команда узнаёт о своих ошибках; вся их эволюция про то, как получать обратную связь раньше и дешевле. Waterfall — строгие последовательные фазы; ломается, когда требования меняются, потому что ошибка всплывает только в конце и стоит дорого.
• V-модель добавила к Waterfall тестирование на каждый этап проектирования, но осталась плановой и не гибкой к изменениям. Итеративная и инкрементальная разработка разбивают работу на короткие циклы, давая обратную связь после каждого, а не в конце проекта.
• Agile — это не метод, а набор ценностей (Agile Manifesto): работающий продукт, обратная связь, адаптация; под ним живут Scrum, Kanban, XP. Выбор зависит от стабильности требований: жёсткие требования и регуляторика — плановые модели, неопределённость и частая обратная связь — Agile; «правильной» модели нет, есть подходящая под задачу.
• Спираль Боэма делает витки вокруг рисков, RUP доказывает архитектуру каркасом до функций; из них берут список рисков первым артефактом и тонкий срез через все слои.
• Модель часто задаёт договор: фиксированный объём требует ТЗ и водопада по форме, оплата по времени делает спринты естественными; смешанные формы соединяют фазу проработки и итерации.
• После выпуска процесс продолжается: дежурство по графику с бюджетом времени и пределом шума, записанная процедура инцидента, разбор без виноватых с действиями в том же бэклоге.
• Инкремент растит набор возможностей и его можно остановить в любой момент, итерация улучшает качество одной возможности и требует ответа «какое качество достаточно».
• Практический вывод V-модели переживает саму модель: проверку формулируют вместе с требованием, и требование, для которого нельзя придумать проверку, сформулировано плохо.
• Гибкий подход ломается без доступного заказчика, при подписанном объёме, при дорогой поставке, когда продукт нельзя выпускать частями, и требует больше дисциплины, а не меньше.
• Смешивают четырьмя способами: план снаружи и итерации внутри, фиксированный срок с гибким объёмом, плановое ядро с гибкой периферией, две скорости для разных частей системы.

Что почитать дальше

• Scrum — работа спринтами, роли и церемонии как самый распространённый способ быть Agile.
• Kanban — визуализация потока задач и WIP-лимиты для непрерывной поставки.
• Extreme Programming — инженерные практики Agile: парное программирование, тесты вперёд кода, частые релизы.
• Оценка и планирование — story points и velocity: как короткие циклы превращаются в прогноз сроков.