За пределами прямой линии
Waterfall и V-модель разделяют фундаментальное допущение: можно определить всё заранее и выполнить за один проход. На практике это допущение не работает для большинства проектов. Требования меняются. Пользователи дают обратную связь, которая обесценивает допущения. Технологии развиваются. Конкуренты выпускают функции, меняющие приоритеты.
Итеративная и инкрементальная модели разработки решают эту реальность, разбивая проект на меньшие циклы, каждый из которых производит работающее ПО, которое можно тестировать, демонстрировать и улучшать.
Итеративная разработка: улучшение через повторение
Итеративная разработка сначала создаёт весь продукт в грубой форме, затем улучшает его через повторяющиеся циклы. Каждая итерация производит более полную и отшлифованную версию всей системы.
Представьте скульптора: он не вырезает левую руку идеально, затем правую, затем голову. Сначала намечает всю фигуру целиком, затем добавляет детали последовательными проходами. Каждый проход улучшает всю скульптуру.
Как это работает
- Итерация 1: Создать базовую версию всей системы — простой UI, основная логика, минимальная работа с данными
- Итерация 2: Улучшить UI на основе обратной связи, усовершенствовать логику, добавить обработку ошибок
- Итерация 3: Отполировать UI, оптимизировать производительность, обработать граничные случаи
- Итерация N: Финальные улучшения до соответствия критериям приёмки
Каждая итерация включает все активности SDLC: планирование, проектирование, кодирование, тестирование и обзор. Продукт эволюционирует через каждый цикл.
Грубый прототип] --> I2[Итерация 2
Улучшенная версия] I2 --> I3[Итерация 3
Отшлифованная версия] I3 --> I4[Итерация N
Готова к релизу] I1 -.->|Обратная связь| I2 I2 -.->|Обратная связь| I3 I3 -.->|Обратная связь| I4 style I1 fill:#fca5a5 style I2 fill:#fcd34d style I3 fill:#86efac style I4 fill:#22c55e,color:#fff
Тестирование в итеративной разработке
Тестирование происходит в каждой итерации:
- Итерация 1: Тестирование базовой функциональности — работает ли основной поток вообще?
- Итерация 2: Тестирование улучшений — работают ли улучшения без поломки существующих функций?
- Итерация 3: Тестирование атрибутов качества — производительность, безопасность, удобство
- Каждая итерация: Регрессионное тестирование для уверенности, что предыдущая функциональность работает
Ключевое преимущество: дефекты находят за дни или недели, а не месяцы. Когда итерация 2 ломает что-то из итерации 1, команда исправляет это немедленно, пока контекст свеж.
Инкрементальная разработка: строим по частям
Инкрементальная разработка строит продукт отдельными частями (инкрементами), каждая из которых добавляет новую функциональность. В отличие от итеративной, каждый инкремент должен быть завершённым и готовым к продакшену.
Представьте строительство дома комната за комнатой: сначала кухня (полностью готова, пригодна к использованию), затем спальня, затем ванная. Каждая комната готова при доставке.
Как это работает
- Инкремент 1: Создать и полностью протестировать модуль регистрации и входа
- Инкремент 2: Создать и полностью протестировать каталог товаров и поиск
- Инкремент 3: Создать и полностью протестировать корзину и оформление заказа
- Инкремент 4: Создать и полностью протестировать обработку платежей
Модуль входа] --> Inc2[Инкремент 2
+ Каталог] Inc2 --> Inc3[Инкремент 3
+ Корзина] Inc3 --> Inc4[Инкремент 4
+ Платежи] style Inc1 fill:#3b82f6,color:#fff style Inc2 fill:#6366f1,color:#fff style Inc3 fill:#8b5cf6,color:#fff style Inc4 fill:#a855f7,color:#fff
Тестирование в инкрементальной разработке
Каждый инкремент тщательно тестируется перед переходом к следующему:
- Тестирование инкремента: Полное тестирование нового инкремента — модульное, интеграционное, системное
- Интеграционное тестирование: Проверка работы нового инкремента со всеми предыдущими
- Регрессионное тестирование: Уверенность, что предыдущие инкременты работают после добавления нового
Итеративный + инкрементальный: комбинация
На практике большинство современной разработки сочетает оба подхода:
- Продукт строится инкрементально (функция за функцией)
- Каждая функция улучшается итеративно (несколько проходов в рамках каждого инкремента)
Именно это делают Agile-методологии (Scrum, Kanban): каждый спринт доставляет работающий инкремент, итеративно улучшенный в ходе спринта.
Спиральная модель
Спиральная модель, предложенная Барри Боэмом в 1986 году, — конкретная итеративная модель с явным анализом рисков на каждом цикле. Она исторически важна, поскольку повлияла на все последующие итеративные подходы.
Каждый цикл спирали имеет четыре квадранта:
- Определить цели: Чего мы хотим достичь в этом цикле?
- Определить и устранить риски: Что может пойти не так? Как смягчить?
- Разработать и протестировать: Построить и верифицировать решение
- Спланировать следующую итерацию: Что мы узнали? Что дальше?
цели] --> R[2. Определить и
устранить риски] R --> D[3. Разработать
и протестировать] D --> P[4. Спланировать
следующую итерацию] P --> O style O fill:#3b82f6,color:#fff style R fill:#ef4444,color:#fff style D fill:#22c55e,color:#fff style P fill:#f59e0b,color:#fff
Ключевой вклад спиральной модели: разработка, управляемая рисками. Наиболее рискованные элементы строятся и тестируются первыми. Если технологический выбор рискован, первый цикл спирали создаёт прототип для его валидации.
Прототипирование
Прототипирование — итеративная техника, применяемая в любой модели:
Одноразовое прототипирование: Быстро построить грубую версию для валидации идеи, затем выбросить и построить реальную систему. Прототип — не продакшен-код, а инструмент обучения.
Эволюционное прототипирование: Построить прототип и непрерывно улучшать, пока он не станет финальным продуктом.
Для тестирования прототипирование ценно тем, что пользователи могут дать обратную связь по работающему прототипу до полной разработки.
Сравнение с Waterfall
| Аспект | Waterfall | Итеративная/инкрементальная |
|---|---|---|
| Обратная связь | В конце | После каждой итерации/инкремента |
| Работающее ПО | Поздно | Рано и непрерывно |
| Риск | Высокий (позднее обнаружение) | Ниже (раннее обнаружение) |
| Работа с изменениями | Сложно и дорого | Ожидаемо и управляемо |
| Тестирование | Одна фаза в конце | Непрерывно на протяжении всего |
| Стоимость дефектов | Высокая (поздно найдены) | Ниже (рано найдены) |
| Документация | Полная заранее | Эволюционирующая, легче |
| Вовлечение заказчика | Начало и конец | На протяжении всего |
| Лучше для | Стабильные требования | Меняющиеся требования |
Упражнение: выберите правильный подход
Для каждого сценария определите, что более уместно — итеративный, инкрементальный или Waterfall, и объясните:
Компания медицинских устройств строит ПО для инсулиновой помпы. FDA требует полную документацию, трассируемость и формальную верификацию до одобрения.
Стартап строит приложение соцсети для владельцев домашних животных. У них 6 месяцев финансирования и нужно быстро найти product-market fit.
Банку нужно заменить 20-летнюю основную банковскую систему. Существующая обрабатывает $2 миллиарда транзакций ежедневно.
Игровая студия разрабатывает мобильный пазл. Хотят протестировать разные игровые механики с пользователями для поиска наиболее увлекательного дизайна.
Подсказка
Учтите: насколько стабильны требования? Насколько критична система? Сколько обратной связи нужно? Есть ли регуляторные ограничения?Решение
Waterfall (или V-модель) — ПО медицинских устройств требует обширной документации, трассируемости от требований до тестов и формальной верификации. Регуляторное одобрение (FDA) требует полной, аудируемой документации.
Итеративный — Стартап не знает точно, чего хотят пользователи. Нужно строить, тестировать с реальными пользователями, учиться и улучшать быстро. Итеративный подход (Agile/Scrum) позволяет валидировать допущения каждые 2 недели.
Инкрементальный — Замена основной банковской системы не может произойти одномоментно (риск big-bang). Инкрементальный подход мигрирует по одному модулю: сначала сберегательные счета, затем текущие, затем кредиты. Каждый инкремент полностью тестируется и интегрируется.
Итеративный — Игровые механики нужно прототипировать, тестировать с пользователями и улучшать на основе метрик вовлечённости. Команде стоит строить грубые версии разных механик и итерировать.
Профессиональные советы
Совет 1: Регрессионное тестирование — цена итерации. Каждый раз, когда вы что-то меняете в итерации, рискуете сломать что-то из предыдущей. Автоматизация регрессионного тестирования не опциональна в итеративной разработке — это фундамент. Инвестируйте в автоматизацию тестов рано.
Совет 2: Определите «готово» для каждого инкремента. В инкрементальной разработке каждый инкремент должен соответствовать чёткому определению готовности — включая тестирование. «Модуль логина готов» должно означать «закодирован, покрыт unit- и интеграционными тестами, прошёл code review и документирован».
Совет 3: Используйте итерации для снижения рисков, а не только доставки функций. Если вы не уверены, что технология сработает, посвятите первую итерацию созданию прототипа и его тщательному тестированию. Не ждите последней итерации, чтобы обнаружить, что архитектура не выдерживает нагрузку.
Ключевые выводы
- Итеративная разработка улучшает весь продукт через повторяющиеся циклы
- Инкрементальная разработка строит продукт по частям, каждая часть полностью протестирована
- Современная разработка (Agile) сочетает оба подхода: инкрементальная доставка с итеративным улучшением
- Спиральная модель добавила анализ рисков, повлияв на все современные подходы
- Тестирование происходит в каждой итерации и инкременте, находя дефекты рано
- Автоматизация регрессии необходима в итеративной/инкрементальной разработке
- Выбор модели SDLC зависит от контекста: стабильности требований, уровня риска, регуляторных нужд и потребности в обратной связи