Методологии разработки ПО делятся на две группы. Каскад (Waterfall) и V-модель проходят этапы строго по очереди и годятся, когда требования известны заранее, а ошибка стоит дорого. Гибкие Agile, Scrum, Kanban и RAD подходят продуктам, которые уточняются по ходу, а на практике обе группы часто смешивают.
Что такое методология разработки программного обеспечения
Это правила игры для команды и заказчика: кто принимает решения, как часто показывают результат, как фиксируют требования и что делать, когда они меняются. С такими правилами проект управляем — бюджет и сроки понятны, риски видны заранее. Неудачно выбранная методология оборачивается переделками и конфликтами.
Каскадная модель (Waterfall) и V-модель
В каскаде этапы идут строго друг за другом: требования, проектирование, разработка, тестирование, внедрение, поддержка. В России эта логика заложена в стандарты серии ГОСТ 34 на автоматизированные системы, поэтому каскад часто требуют в госзаказе и крупных корпорациях.
V-модель — тот же каскад, но к каждому этапу заранее привязан свой уровень тестирования: требованиям — приёмочные испытания, архитектуре — интеграционные тесты, модулям — модульные. Её выбирают там, где цена ошибки высока: в медицине, промышленности, финансах.
- Плюсы: прозрачный план, понятные бюджет и сроки, полная документация. У V-модели ещё и высокое качество: тесты планируют с первого этапа.
- Минусы: заказчик видит продукт только в конце, а поздно найденные ошибки и новые требования обходятся дорого.
Agile, Scrum и Kanban — гибкие подходы
Agile задаёт принципы: работающий продукт важнее исчерпывающей документации, готовность к изменениям важнее плана. На них построены Scrum, Kanban и экстремальное программирование (XP). Продукт выходит рано и легко меняется, но итоговые сроки и бюджет сложно зафиксировать заранее, а заказчик нужен в работе постоянно.
Scrum делит работу на спринты от одной до четырёх недель: команда берёт задачи из приоритизированного бэклога, каждый день коротко сверяется и в конце спринта показывает заказчику работающую версию. Ритм предсказуемый, результат виден регулярно. Но без вовлечённого владельца продукта, который расставляет приоритеты, Scrum превращается в череду формальных встреч.
Kanban обходится без спринтов: задачи идут потоком по доске «к выполнению — в работе — на проверке — готово», а число задач в работе ограничено, чтобы ничего не зависало. Начать можно с текущего процесса, узкие места сразу видны. Для поддержки и потока заявок он хорош, для планирования крупных релизов — слаб.
RAD и гибридные подходы
RAD (Rapid Application Development, быстрая разработка приложений) строится на прототипах и коротких итерациях: пользователи рано видят работающие версии, требования уточняются по ходу. Сегодня эти идеи живут в low-code-платформах и быстрой разработке MVP. Нужны опытная команда и доступный заказчик, а для больших систем с жёсткими требованиями к архитектуре RAD подходит плохо.
В чистом виде методологии применяют редко. Частый гибрид: требования, архитектура и бюджет фиксируются по-каскадному, а разработка идёт спринтами с демонстрациями. Есть и Scrumban — спринты Scrum плюс доска и лимиты Kanban.
С генеративным ИИ код и документацию пишут быстрее, но методология никуда не девается: узким местом становятся ясные требования, ревью и тестирование.
Критерии выбора методологии разработки
- Требования известны и меняться не будут — каскад или V-модель. Продукт будет уточняться — Agile.
- Фиксированные цена и объём тяготеют к каскаду, оплата по фактически затраченному времени — к гибким подходам.
- Высокая цена ошибки — V-модель с формальными проверками.
- Нужен быстрый первый результат — Scrum или RAD.
- Поддержка и поток мелких задач — Kanban, новый продукт — Scrum, госзаказ — как правило, ГОСТ.
- Гибкие методологии работают, только если заказчик готов регулярно смотреть результат и принимать решения.
Если требования ещё не описаны, начните с них: от ТЗ зависит, получится ли зафиксировать цену и объём или честнее работать итерациями. «Квантум Дев» поможет составить техническое задание и подберёт формат работы под проект — фиксированный объём для ясных требований или короткие итерации с регулярными демонстрациями.
