Методология разработки ПО — это договоренность команды о том, как она превращает требования в работающий продукт: в каком порядке идут работы, когда показывают результат заказчику, как принимают изменения и кто за что отвечает. Самые известные подходы — каскад (Waterfall), V-модель, спиральная модель, Agile и основанные на его принципах Scrum, Kanban и XP, а также RAD. Ниже — что каждый из них собой представляет, сводная таблица и пошаговый способ выбрать подход под конкретный проект.
Содержание
Модель, методология, фреймворк: мини-словарь
Эти слова часто используют как синонимы, из-за чего сравнения выглядят противоречиво. Развести их стоит сразу:
- Модель жизненного цикла — схема, в каком порядке проходят этапы (требования, проектирование, код, тестирование, внедрение). Примеры: каскадная, V-образная, итеративная, спиральная.
- Методология — модель плюс правила работы: роли, артефакты, встречи, критерии готовности. Примеры: RUP, RAD.
- Фреймворк или метод — компактный набор правил, который команда дополняет своими практиками. Scrum официально называет себя фреймворком, Kanban — методом управления потоком работ.
- Agile — не методология, а набор ценностей и принципов (Agile-манифест, 2001). Scrum, Kanban и XP — способы жить по этим принципам.
Упрощение: границы между категориями размыты, и в вакансиях все это называют «методологиями». Но при сравнении важно понимать, что Waterfall и Scrum отвечают на разные вопросы: первый — в каком порядке идут этапы, второй — как команда организует короткие циклы работы.
Сами этапы жизненного цикла (от идеи до поддержки) подробно разобраны в статье о жизненном цикле приложения и стадиях разработки, здесь — только подходы к их организации.
Предиктивные подходы: план сначала
Каскадная модель (Waterfall)
Этапы идут строго по очереди: требования -> проектирование -> реализация -> тестирование -> внедрение -> сопровождение. Следующий этап начинается, когда предыдущий завершен и принят.
Происхождение модели часто связывают со статьей Уинстона Ройса 1970 года. Любопытная деталь: сам Ройс называл чисто последовательный вариант рискованным и предлагал возвраты между этапами, а слово «водопад» закрепилось позже.
Сильные стороны — предсказуемые сроки и бюджет на старте, полная документация, простой контроль по этапам. Слабые — заказчик видит продукт только в конце, а ошибка в требованиях часто обнаруживается только на тестировании, когда ее исправление обходится намного дороже, чем на этапе требований.
Каскад уместен, когда требования стабильны и формально зафиксированы: госзаказ по техническому заданию, встроенное ПО под известное железо, миграция системы с понятным объемом.
V-модель
Развитие каскада, в котором каждому этапу проектирования сразу ставится в пару уровень проверки:
| Этап проектирования | Парный уровень тестирования |
|---|---|
| Бизнес-требования | Приемочное тестирование |
| Системные требования | Системное тестирование |
| Архитектура | Интеграционное тестирование |
| Детальный дизайн модулей | Модульное тестирование |
Тест-планы пишут параллельно с требованиями, поэтому противоречия находят раньше. V-модель распространена там, где требуется доказуемая проверка: медицинские изделия, автомобильная электроника, авиация и железная дорога — отрасли со стандартами, которые ожидают трассировку «требование -> тест».
Важно не путать: V-модель — это не TDD (разработка через тестирование). В TDD программист пишет тест перед каждым небольшим куском кода, в V-модели тестовые уровни планируются от этапов проектирования, а исполняются после реализации.
Спиральная модель
Предложена Барри Боэмом во второй половине 1980-х. Работа идет витками, и в каждом витке команда определяет цели, анализирует риски, делает прототип или часть системы и планирует следующий виток. Главное отличие от остальных моделей — явное управление рисками на каждом шаге. Цена — высокая стоимость анализа, поэтому спираль применяют в крупных и рискованных проектах, а не в небольших.
Итеративные и гибкие подходы: результат часто
Общая идея — выпускать работающую часть продукта короткими циклами и корректировать план по обратной связи. Разница между итеративным и инкрементным подходом — отдельная большая тема; здесь достаточно того, что Agile-практики используют оба приема.
Agile
В феврале 2001 года 17 практиков сформулировали Agile-манифест: 4 ценности и 12 принципов. Суть ценностей: люди и взаимодействие важнее процессов и инструментов, работающий продукт важнее исчерпывающей документации, сотрудничество с заказчиком важнее согласования условий контракта, готовность к изменениям важнее следования плану. Манифест не отменяет правую часть этих пар — он говорит о приоритете.
Scrum
Работа идет спринтами фиксированной длины — не больше месяца, чаще 1-2 недели. По Scrum Guide 2020 в команде три зоны ответственности: Product Owner (ценность продукта и порядок бэклога), Scrum Master (эффективность процесса) и Developers (создают инкремент). События: сам спринт как контейнер и четыре события внутри него — планирование спринта, ежедневный Scrum, обзор спринта и ретроспектива. Цель спринта во время спринта не меняют, но объем работ можно уточнять с Product Owner, если это не ставит цель под угрозу. Подробно роли и события разобраны в статье о Scrum от А до Я.
Kanban
Метод управления потоком задач, пришедший в разработку из производственной системы Toyota. Задачи движутся по доске со столбцами (например, «Сделать -> В работе -> Проверка -> Готово»), а у столбцов есть лимиты незавершенной работы (WIP-лимиты). Спринтов и обязательных ролей нет, поток непрерывный. Kanban хорошо подходит для поддержки и эксплуатации, где задачи приходят неравномерно.
XP (экстремальное программирование)
Сформулировано Кентом Беком в конце 1990-х и, в отличие от Scrum, описывает инженерные практики: парное программирование, TDD, непрерывная интеграция, частые маленькие релизы, рефакторинг, коллективное владение кодом. На практике XP-практики часто используют внутри Scrum.
RAD (быстрая разработка приложений)
Подход, популяризированный Джеймсом Мартином в начале 1990-х: быстрое прототипирование вместе с пользователями, короткие сроки (timebox), активное использование готовых компонентов и визуальных инструментов. Подходит для внутренних бизнес-приложений с понятной предметной областью и плохо — для высоконагруженных и критичных систем, где прототип трудно довести до промышленного качества. Современный наследник идеи — low-code-платформы.
Сравнительная таблица методологий
| Подход | Тип | Когда видно результат | Изменения требований | Документация | Где уместен |
|---|---|---|---|---|---|
| Waterfall | Модель, предиктивная | В конце проекта | Дорого, через формальное изменение ТЗ | Полная | Стабильные требования, фиксированный контракт |
| V-модель | Модель, предиктивная | В конце, с проверкой по уровням | Дорого | Полная, с трассировкой к тестам | Регулируемые отрасли, безопасность |
| Спиральная | Модель, риск-ориентированная | В конце каждого витка | Возможны между витками | Значительная | Крупные рискованные проекты |
| Scrum | Фреймворк, Agile | Каждый спринт (до 1 месяца) | Бэклог — в любой момент, цель спринта — между спринтами | Минимально достаточная | Продукт с неопределенными требованиями |
| Kanban | Метод, Agile/Lean | Непрерывно, по задаче | В любой момент | Минимально достаточная | Поддержка, эксплуатация, поток заявок |
| XP | Инженерные практики, Agile | Частые маленькие релизы | Легко | Код и тесты как документация | Небольшая команда, высокий темп изменений |
| RAD | Методология, прототипная | Прототипы за недели | Легко на этапе прототипов | Облегченная | Внутренние бизнес-приложения |
Таблица описывает типичное применение, а не закон: Scrum-команда может вести подробную документацию, а каскадный проект — показывать заказчику промежуточные сборки.
Как выбрать методологию под проект
Идти по вопросам сверху вниз — каждый ответ сужает выбор:
- Насколько стабильны требования? Зафиксированы в ТЗ и вряд ли изменятся — смотреть в сторону каскада или V-модели. Будут уточняться по ходу — Agile-подходы.
- Есть ли регулятор или обязательная сертификация? Нужна доказуемая связь «требование -> тест» — V-модель или гибрид с ее формальными проверками.
- Как устроен контракт? Фиксированная цена и объем тянут к предиктивному плану; оплата по времени и работе (time and materials) проще сочетается со Scrum.
- Какой характер работы? Развитие продукта крупными порциями — Scrum; поток разнородных заявок без планируемых фич — Kanban.
- Насколько высоки технические риски? Много неизвестного в технологии — спираль или серия прототипов до основной разработки.
- Какой размер и опыт команды? Небольшая команда опытных инженеров — Scrum или Kanban с практиками XP; несколько команд над одним продуктом — понадобится масштабирование (например, LeSS или SAFe).
Пример. Интернет-магазин книг для небольшого издательства: требования заказчик уточняет по мере запуска, бюджет помесячный, команда из пяти человек. Ответы на вопросы 1, 3 и 6 указывают на Scrum с двухнедельными спринтами. После запуска, когда основная работа — это правки и заявки от поддержки, команда может перейти на Kanban.
Другой случай — прошивка медицинского монитора: требования заданы стандартом, нужна сертификация, изменения дорогие. Здесь уместна V-модель, а гибкие практики возможны разве что внутри отдельных этапов.
На практике многие компании используют гибриды: план и бюджет верхнего уровня по каскаду, а разработку — спринтами. Это нормально, если команда понимает, какую часть процесса какой подход обслуживает.
Выводы
- Модель жизненного цикла, методология, фреймворк и Agile — разные уровни: сравнивать Waterfall со Scrum напрямую можно, но нужно помнить, что они отвечают на разные вопросы.
- Предиктивные подходы (Waterfall, V-модель) выигрывают при стабильных требованиях и формальной проверке, проигрывают при частых изменениях.
- Scrum, Kanban и XP — способы применять принципы Agile-манифеста: Scrum организует работу спринтами, Kanban управляет потоком, XP задает инженерные практики.
- Методологию выбирают по стабильности требований, регуляторике, типу контракта, характеру работы, рискам и размеру команды; гибриды — обычная практика.
Где применяется / связь с практикой
Освойте тему на практике
Выбор и настройка процесса — основная задача руководителя проекта: он решает, как часто показывать результат, как принимать изменения и как считать сроки. Если хочется разобраться в этом системно, на курсе «Менеджер Agile-проектов» разбирают Scrum, Kanban и управление гибкими проектами на практических кейсах. Познакомиться с темой бесплатно можно на открытых уроках Otus.
FAQ
Можно ли сменить методологию в середине проекта?
Можно, и так часто делают: например, после запуска продукта переходят со Scrum на Kanban. Переход стоит проводить явно — договориться о новых правилах, ролях и метриках, а не менять процесс незаметно.
Что спрашивают о методологиях на собеседовании?
Обычно просят сравнить каскад и Agile, объяснить разницу между Scrum и Kanban и рассказать, по какому процессу работал сам. Хороший ответ опирается на опыт: длина спринта, кто ставил задачи, как проходили ретроспективы.
Agile — это значит без документации и без планирования?
Нет. Манифест ставит работающий продукт выше исчерпывающей документации, но не отменяет ее, а в Scrum планирование проходит в начале каждого спринта.
