Модели разработки
Каскадная модель (Waterfall)
Каскадная модель - последовательный процесс разработки, где каждый этап начинается только после завершения предыдущего. Разработал данную модель Уинстон Ройс в 1970 году.
Модель подходит для простых и быстрых проектов в заказной разработке, где требования известны заранее и вряд ли изменятся. Для сложных проектов она не подходит, потому как в них существует кратно большее количество неизвестных переменных.
Этапы выполняются строго друг за другом: сбор требований, проектирование, реализация, тестирование, внедрение, поддержка. На практике мы получаем модель, в которой постоянно приходится возвращаться обратно и дорабатывать прошлые этапы.
Критические недостатки, которые не дают воспользоваться моделью в больших проектах:
- В конце получается не то, что нужно, потому что все требования были приняты в самом начале пути
- Слишком поздно идёт тестирование продукта
- Очень тяжело попасть в сроки и бюджет, так как внести правки становится сложно
- Внесение изменений - это проблема, так как в начале такой функционал не предусматривался
Плюсы модели:
- Простота управления - каждый этап имеет чёткие deliverables и точки контроля
- Хорошо документирован каждый этап
- Подходит для проектов с фиксированными требованиями и регуляторными ограничениями
V-модель
V-модель - расширение каскадной модели, где каждому этапу разработки соответствует свой этап тестирования. Левая ветвь V описывает декомпозицию требований и создание проектной документации, а правая - интеграцию и валидацию на каждом уровне.
Соответствие этапов:
| Этап разработки | Этап тестирования |
|---|---|
| Сбор требований | Приёмочное тестирование |
| Системное проектирование | Системное тестирование |
| Архитектура | Интеграционное тестирование |
| Детальный дизайн модулей | Модульное тестирование |
Модель активно применяется в отраслях с повышенными требованиями к безопасности - автомобилестроение (ISO 26262), авиация (DO-178C), медицинское оборудование (IEC 62304). В этих доменах стоимость ошибки крайне высока, поэтому формальная верификация на каждом уровне оправдана.
Плюсы:
- Ранее планирование тестов - тест-кейсы создаются параллельно с проектированием
- Дефекты обнаруживаются раньше, чем в классическом Waterfall
- Высокая прослеживаемость требований
Минусы:
- Такая же негибкость к изменениям, как и в Waterfall
- Не подходит для проектов с нечёткими или эволюционирующими требованиями
- Высокая стоимость документации
Спиральная модель
Спиральная модель, предложенная Барри Боэмом в 1986 году, опирается на потребность в изготовлении раннего прототипа, тестировании и анализе рисков. Каждый виток спирали проходит через четыре квадранта: определение целей, анализ рисков, разработка и тестирование, планирование следующей итерации.
Здесь находится достаточно большое количество шагов, на которых мы проверяем прототипы и анализируем потребности в разработке фичей, что может замедлять процесс разработки.
Плюсы:
- Фокус на управлении рисками - самые рискованные части разрабатываются первыми
- Раннее прототипирование позволяет получить обратную связь до полной реализации
- Гибкость в выборе подхода на каждом витке
Недостатки:
- Тестирование реального продукта происходит на позднем этапе
- Частые промахи по срокам и бюджету
- Долгий Time to Market
- Требует высокой квалификации в оценке рисков
- Сложность в управлении для небольших проектов
Rational Unified Process (RUP)
RUP использует итеративную модель разработки. В конце каждой итерации проектная команда должна достичь запланированных целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итерации в идеале продолжаются от 2 до 6 недель.
Процесс делится на четыре фазы: Inception (начало), Elaboration (проработка), Construction (построение), Transition (внедрение). Каждая фаза может содержать несколько итераций.
Плюсы:
- Ранняя идентификация и устранение рисков
- Концентрация на выполнении требований заказчика
- Изменения в продукте от заказчика ожидаются
- Компонентная архитектура, которая реализуется и тестируется на ранних стадиях
- Постоянное обеспечение качества на всех этапах разработки продукта
- Работа в сплочённой команде с ключевой ролью у архитекторов
Недостатки:
- Большой Time to Market
- Срыв сроков и бюджета
- Тяжеловесность фреймворка - большое количество артефактов и ролей
- Тестирование реального продукта происходит на позднем этапе
Впоследствии IBM переименовала RUP в OpenUP, сделав его более легковесным и открытым. OpenUP сохраняет ключевые принципы RUP, но убирает избыточную формализацию.
Waterfall vs Agile
Идейно Waterfall - это подход, который крайне актуален в проектной разработке. Тут нужно поделить чётко зоны ответственности, где каждый будет выполнять свою роль и быстро закрывать задачу. Никаких идей, только сухое решение проблем заказчика.
Agile - это обратная сторона, где постоянно ищутся идеи, поощряется инициатива, ведётся разработка ценности. Он актуален для продуктового подхода. Тут важно найти свой особенный подход для продукта.
Waterfall стремится за производительностью, а Agile за результативностью.
Особенности
| Метрика | Проектный подход (Waterfall) | Продуктовый подход (Agile) |
|---|---|---|
| Цель | Выполнить в срок и бюджет | Достичь целей и максимизировать ценность |
| Фокус | Завершение проекта | Удовлетворение потребности пользователя |
| Длительность | Явное начало и конец | Продолжается, пока приносит ценность |
| Мера успеха | Соблюдён бюджет, сдан в срок, воспроизведено заявленное качество | Метрики, удовлетворение пользователя, рыночная доля, рентабельность |
Культура
| Проектный подход | Продуктовый подход |
|---|---|
| Специализация | Открытость к изменениям |
| Иерархия | Сотрудничество |
| Аналитические навыки | Самоорганизация |
| Планирование и исполнение | Прозрачность |
| Дисциплина и ответственность | Постоянное обучение и рефлексия |
| Ориентация на процесс | Постоянное улучшение продукта |
| Исполнительность и терпение | Высокая мотивация |
| Ценность-дривен мышление |
В Agile методологии очень важно пропагандировать ценности продукта, лучшие практики и правильные подходы, чтобы у команды была цель реализовать лучшую версию продукта.
Сравнение
| Waterfall | Agile |
|---|---|
| Очень прибылен | Позволяет создавать сложные продукты, которые, возможно, ещё никто никогда не разрабатывал |
| Снижаются требования к разработчику | Очень способствует развитию |
| Легко масштабируется за счёт воспроизводимых процессов |
Agile создаёт продукт, а Waterfall его воспроизводит
Когда какую модель использовать
Выбор модели разработки зависит от контекста проекта. Нет универсально лучшей модели - есть модель, подходящая под конкретные условия.
Waterfall подходит, когда требования зафиксированы и не будут меняться, проект короткий и понятный, или индустрия требует формальной документации каждого этапа. Типичные примеры - госзаказы, миграции данных, интеграции с фиксированным API.
V-модель выбирается в отраслях с высокой ценой ошибки, где верификация и валидация на каждом уровне обязательны по стандартам. Если продукт может повлиять на жизнь и здоровье людей - это скорее всего V-модель.
Спиральная модель полезна в проектах с высоким уровнем неопределённости и рисков, где нужно сначала проверить гипотезы через прототипы. Часто используется в R&D и оборонных проектах.
RUP/OpenUP оправдан для крупных enterprise-проектов со сложной архитектурой, где нужна итеративность, но при этом важна формальная структура процесса и ролей.
Agile/Scrum - выбор для продуктовой разработки с нечёткими или меняющимися требованиями, где важна скорость доставки ценности и постоянная обратная связь от пользователей.
Сводная таблица
| Модель | Лучше всего для | Размер команды | Толерантность к риску | Гибкость |
|---|---|---|---|---|
| Waterfall | Фиксированные требования, регулируемые отрасли, короткие проекты | Любой | Низкая | Минимальная |
| V-модель | Safety-critical домены, сертифицируемые системы | Средний - большой | Очень низкая | Минимальная |
| Спиральная | Высокий риск, R&D, раннее прототипирование | Средний - большой | Высокая | Средняя |
| RUP/OpenUP | Enterprise, сложная архитектура, большие команды | Большой | Средняя | Средняя |
| Agile/Scrum | Продуктовая разработка, инновации, неопределённые требования | Малый - средний | Высокая | Высокая |
Размер команды - не жёсткое ограничение. Agile масштабируется через фреймворки типа SAFe, LeSS и Nexus, а Waterfall может использоваться в маленьких командах на коротких проектах.
Гибридные подходы
На практике большинство организаций не используют модели в чистом виде. Гибридные подходы комбинируют элементы разных моделей, адаптируя процесс под реальные условия.
Water-Scrum-Fall
Самый распространённый гибрид. Планирование и утверждение бюджета проходят по каскадной модели, непосредственно разработка ведётся по Scrum с итерациями, а релиз и внедрение снова следуют формальному каскадному процессу.
Такой подход часто встречается в крупных компаниях, где руководство требует предсказуемость сроков и бюджета, но команды разработки хотят гибкости внутри итераций.
Когда гибрид оправдан
- Организация переходит от Waterfall к Agile и не может перестроить всё сразу
- Часть проекта имеет фиксированные требования (интеграция с внешней системой), а часть - неопределённые (пользовательский интерфейс)
- Регуляторные требования обязывают к формальной документации на определённых этапах, но внутри этих рамок команда может работать итеративно
- Разные компоненты системы находятся на разных стадиях зрелости
Гибридный подход - это осознанный выбор, а не оправдание для хаотичного процесса. Команда должна чётко понимать, какие элементы каких моделей она использует и почему.