Когда над продуктом работает больше одного человека, появляется вопрос: в каком порядке всё делать? Сначала собрать все требования или начать кодить сразу? Тестировать в конце или на каждом шаге? Показывать заказчику готовое или промежуточное? Ответы на эти вопросы и есть модель разработки — договорённость о том, как команда движется от идеи к работающему продукту.
Моделей за десятилетия придумали много, и они не случайны: каждая появилась как ответ на боль предыдущей. Разберём главные по порядку — от строгого «каскада» до гибких подходов — и увидим, почему индустрия шла именно в эту сторону.
Зачем вообще модель процесса
Представьте, что пять человек строят дом без общего плана. Один заливает фундамент, другой уже клеит обои в воздухе, третий заказал окна не того размера. Хаос. С софтом то же самое: без договорённости о порядке шагов работа рассыпается на несогласованные куски.
Модель процесса отвечает на три практических вопроса:
- Порядок. Что делаем сначала, что потом — требования, дизайн, код, тестирование, поставка.
- Границы. Когда этап считается законченным и можно двигаться дальше.
- Обратная связь. В какой момент мы узнаём, что ошиблись, и насколько дорого это исправить.
Именно третий пункт — обратная связь — оказался ключевым. Вся эволюция моделей разработки по сути про одно: как узнавать об ошибках раньше и дешевле. Чем позже всплывает ошибка в требованиях или архитектуре, тем дороже её чинить. Ранние модели узнавали поздно, поздние — рано. В этом вся история.
Waterfall: этапы строго по порядку
Waterfall (каскадная модель) — самый ранний и самый интуитивный подход. Работа делится на фазы, которые идут строго друг за другом, как вода падает с уступа на уступ:
- Сбор и фиксация требований.
- Проектирование (архитектура, дизайн).
- Разработка (написание кода).
- Тестирование.
- Поставка и сопровождение.
Каждая фаза завершается полностью до начала следующей. Требования зафиксировали, подписали — переходим к проектированию и назад не возвращаемся. Всё задокументировано, у каждого этапа понятный результат, планировать легко.
Звучит логично — и для некоторых задач так и есть. Проблема в предположении, которое лежит в основе: что все требования известны и не изменятся до конца проекта. В реальной разработке это почти всегда не так. Заказчик сам не знает точно, чего хочет, пока не увидит первую версию. Рынок меняется. Технология оказывается не той.
И вот где Waterfall ломается: ошибка, допущенная на этапе требований, обнаруживается только на этапе тестирования — через месяцы. К этому моменту на неверном фундаменте уже построены проектирование и весь код. Исправление стоит в десятки раз дороже, чем если бы ошибку заметили сразу. Продукт целиком собирается только в самом конце — и до этого момента никто не видел, работает ли он вообще.
V-модель: тестирование привязано к каждому этапу
V-модель — это Waterfall, который попытался вылечить одну конкретную болезнь: тестирование в самом конце. Идея простая — каждому этапу проектирования сопоставить свой уровень тестирования. Отсюда и форма буквы V: левая ветка спускается от общих требований к коду, правая поднимается обратно через уровни проверки.
| Этап (спуск) | Соответствующий уровень тестирования (подъём) |
|---|---|
| Требования к системе | Приёмочное тестирование |
| Архитектура системы | Системное тестирование |
| Детальный дизайн модулей | Интеграционное тестирование |
| Написание кода | Модульное (unit) тестирование |
Смысл в том, что о тестировании думают заранее, вместе с проектированием. Планируя требования, вы сразу описываете, как будете проверять, что они выполнены. Это заставляет формулировать требования проверяемо и ловить часть ошибок раньше — на бумаге, а не в готовом продукте.
Но фундаментально V-модель осталась плановой и последовательной. Она по-прежнему предполагает, что требования известны заранее и стабильны. Гибкости к изменениям она не добавила — только дисциплину в тестировании. Поэтому V-модель хорошо живёт там, где требования действительно жёсткие: медицинское оборудование, авиация, встроенные системы.
Итеративная и инкрементальная разработка: не всё сразу
Следующий шаг был концептуально важнее. Раз мы не можем знать все требования заранее — давайте не будем и пытаться. Разобьём работу на короткие циклы и после каждого будем смотреть на результат.
Здесь стоит различать два близких слова:
- Инкрементальная разработка — продукт растёт по кусочкам (инкрементам). Сначала делаем базовую версию с частью функций, потом добавляем следующую порцию, потом ещё. Каждый инкремент — работающий кусок, который расширяет предыдущий.
- Итеративная разработка — мы возвращаемся к уже сделанному и улучшаем его на каждом круге (итерации). Первая версия грубая, вторая точнее, третья почти готовая.
На практике их обычно совмещают: каждый цикл и добавляет новое, и улучшает старое. Главное отличие от Waterfall — обратная связь появляется после каждого цикла, а не в самом конце. Ошиблись в понимании задачи — узнали через две недели, а не через полгода, и потеряли только эти две недели работы.
Именно эта идея — короткие циклы с проверкой результата — стала фундаментом для всего, что появилось дальше.
Agile: не метод, а набор ценностей
Здесь важно понять частую путаницу. Agile — это не методология и не набор инструкций. Это набор ценностей, зафиксированный в 2001 году в документе под названием Agile Manifesto. Его подписали разработчики, уставшие от тяжёлых плановых процессов, и сформулировали, что для них важнее.
Манифест построен как четыре противопоставления «важнее — чем»:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее жёстких условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Обратите внимание: правая часть не отменяется. Документация нужна, план нужен — но когда приходится выбирать, приоритет отдаётся левой части. Работающий продукт, частая обратная связь и адаптация к изменениям — вот три опоры Agile.
Ключевое для понимания: Agile сам по себе не говорит, что делать по понедельникам. Он задаёт направление, а конкретные практики строят под ним. Agile — это зонтик, под которым живут конкретные подходы:
- Scrum — работа короткими фиксированными отрезками (sprint), роли, регулярные встречи, backlog задач.
- Kanban — визуализация потока задач на доске и ограничение числа задач в работе (WIP-лимит).
- Extreme Programming (XP) — набор инженерных практик: парное программирование, тесты вперёд кода, частые релизы.
Все они — способы воплотить одни и те же ценности разными наборами практик. Поэтому спорить «Scrum или Agile» бессмысленно: Scrum и есть один из способов быть Agile.
Как выбирать модель под задачу
Главная ошибка — считать, что есть «правильная» модель, а остальные устарели. Нет. Каждая решает свою задачу, и выбор зависит от двух вопросов: насколько стабильны требования и как дорого обходятся изменения.
Ориентир простой:
- Требования жёсткие, зафиксированы, есть регуляторика и ответственность за жизнь и деньги (медтех, авиация, банковское ядро, госстандарты) — плановые модели (Waterfall, V-модель). Здесь ценна предсказуемость и полный след документации, а изменения по ходу редки и дороги в любом случае.
- Требования неопределённые, продукт новый, важна частая обратная связь от пользователей (стартап, новый цифровой продукт, исследовательская задача) — Agile-подходы. Здесь способность быстро менять курс важнее детального плана на год вперёд.
В реальности чистых случаев мало, и команды часто смешивают: жёсткое плановое ядро с фиксированными интеграциями и гибкая надстройка вокруг пользовательских функций. Модель — это инструмент под контекст, а не догма. Правильный вопрос не «какая модель лучше», а «что для этой задачи дороже — ошибиться в плане или потерять предсказуемость».
Коротко
- Модель разработки — договорённость о порядке шагов и о том, когда команда узнаёт о своих ошибках; вся их эволюция про то, как получать обратную связь раньше и дешевле.
- Waterfall — строгие последовательные фазы; ломается, когда требования меняются, потому что ошибка всплывает только в конце и стоит дорого.
- V-модель добавила к Waterfall тестирование на каждый этап проектирования, но осталась плановой и не гибкой к изменениям.
- Итеративная и инкрементальная разработка разбивают работу на короткие циклы, давая обратную связь после каждого, а не в конце проекта.
- Agile — это не метод, а набор ценностей (Agile Manifesto): работающий продукт, обратная связь, адаптация; под ним живут Scrum, Kanban, XP.
- Выбор модели зависит от стабильности требований: жёсткие требования и регуляторика — плановые модели; неопределённость и частая обратная связь — Agile.
- «Правильной» модели нет — есть подходящая под контекст задачи.
Что почитать дальше
- Scrum — работа спринтами, роли и церемонии как самый распространённый способ быть Agile.
- Kanban — визуализация потока задач и WIP-лимиты для непрерывной поставки.
- Extreme Programming — инженерные практики Agile: парное программирование, тесты вперёд кода, частые релизы.