Итеративный подход — это способ разработки, при котором продукт делают повторяющимися циклами (итерациями): в каждом цикле команда планирует, делает, проверяет результат и по обратной связи уточняет план следующего цикла. Инкрементный подход — это выпуск продукта частями (инкрементами): каждая часть добавляет функциональность к уже работающей версии.
Содержание
Это два разных свойства процесса. Итеративность отвечает на вопрос «как часто мы возвращаемся и переделываем», инкрементность — «как мы наращиваем объем». На практике их почти всегда совмещают, и тогда говорят об итеративно-инкрементной разработке: на ней построены Scrum и большинство гибких практик. Ниже — мини-словарь, сравнение с каскадом, разбор на примере мессенджера, плюсы и риски.
Иногда подход ищут под искаженными названиями — «анимеративный» или «интерактивный». В методологиях разработки правильный термин — итеративный (от лат. iteratio — повторение).
Мини-словарь
| Термин | Что это | Пример в мессенджере |
|---|---|---|
| Итерация | Отрезок времени с полным циклом «план — работа — проверка — выводы» | Двухнедельный цикл команды |
| Инкремент | Прирост работающей функциональности по итогам работы | Добавили голосовые сообщения |
| Релиз | Выпуск версии пользователям | Обновление в магазине приложений |
| MVP | Минимальная версия, на которой можно проверить главную гипотезу | Чат на двоих без групп и медиа |
| Обратная связь | Данные о том, как продуктом пользуются: метрики, отзывы, демо заказчику | «Люди просят отправлять фото» |
Итерация не обязана заканчиваться релизом: можно сделать три итерации и выпустить одну версию.
Итеративный и инкрементный: в чем разница
Удобная аналогия — картина (ее популяризировал Джефф Паттон на примере «Моны Лизы»). Инкрементный художник пишет полотно по кускам: сначала полностью и начисто левый верхний угол, потом соседний. Итеративный делает набросок всей картины, затем прорисовывает ее целиком все подробнее, переделывая то, что не получилось.
| Признак | Итеративный | Инкрементный |
|---|---|---|
| Главный вопрос | Что переделать и улучшить по итогам проверки | Какую часть добавить следующей |
| Меняется ли уже сделанное | Да, это нормальная часть работы | В чистом виде — нет, части добавляются |
| Требования | Уточняются по ходу | Могут быть известны заранее и разбиты на части |
| Когда есть что показать | После каждой итерации, но может быть «сырым» | После каждого инкремента, часть уже готова |
| Главный риск | Бесконечная доработка без выпуска | Неверный общий план, который выяснится поздно |
Аналогия упрощенная: чистые варианты встречаются редко. Инкрементную модель с жестким планом частей применяют при стабильных требованиях (поэтапная сдача системы по договору), итеративную без инкрементов — при прототипировании.
Чем оба подхода отличаются от каскада
Каскадная модель (waterfall) проходит этапы один раз и по порядку: требования, проектирование, разработка, тестирование, внедрение. Работающий продукт пользователь видит в конце.
| Критерий | Каскад | Итеративно-инкрементный подход |
|---|---|---|
| Требования | Фиксируются в начале | Уточняются после каждой итерации |
| Первая работающая версия | В конце проекта | После первых итераций |
| Цена позднего изменения | Высокая: нужно вернуться на ранний этап | Ниже: изменение планируют в следующую итерацию |
| Тестирование | Отдельный этап ближе к концу | В каждой итерации |
| Что проще зафиксировать в договоре | Объем, срок и бюджет | Срок и бюджет итерации, объем гибкий |
| Где уместен | Стабильные требования, регулируемые отрасли, жесткий объем | Новые продукты, неясные требования, высокая неопределенность |
Каскад не «устаревший» подход, а инструмент под другие условия: при стабильном объеме последовательные этапы бывают дешевле и прозрачнее.
Как проходит одна итерация
Итерация обычно ограничена по времени (таймбокс). В Scrum такой отрезок называется спринтом, по Scrum Guide его длина — не больше месяца, на практике часто 1-2 недели. Внутри итерации повторяются одни и те же шаги.
- Планирование. Выбрать цель итерации и задачи, которые к ней ведут. Цель формулировать через результат для пользователя: «можно отправить фото», а не «сделать модуль загрузки».
- Разработка. Сделать задачи до состояния «готово»: код, тесты, проверка. Полуготовые задачи в инкремент не входят.
- Проверка. Автотесты и ручная проверка нового и старого поведения.
- Демонстрация и обратная связь. Показать результат заказчику или пользователям, собрать метрики и отзывы.
- Выводы. Решить, что оставить, что переделать, что убрать из плана. Отдельно разобрать сам процесс: что мешало команде.
Без шагов 4-5 итерации превращаются в мини-каскады: отрезки короткие, но план не меняется.
Пример: мессенджер по итерациям
Заказчик хочет мессенджер, но не знает, какие функции нужны аудитории. Вместо полного ТЗ команда проверяет гипотезы.
| Итерация | Цель | Инкремент | Что узнали | Решение |
|---|---|---|---|---|
| 1-2 | Проверить, будут ли переписываться | Регистрация, список контактов, чат на двоих (MVP) | Пользователи возвращаются, но жалуются на задержку сообщений | Следующая итерация — стабильность доставки, а не новые функции |
| 3 | Надежная доставка | Переделана отправка, добавлены статусы «доставлено» и «прочитано» | Жалобы на задержку ушли | Можно наращивать функции |
| 4 | Обмен медиа | Отправка фото | Фото отправляют часто, запросы на видео единичны | Видео отложено, в план — голосовые сообщения |
| 5 | Голосовые | Запись и отправка голосовых | Растет объем хранилища | В план — ограничение размера и сжатие |
Что здесь итеративного, а что инкрементного. Итерация 3 — в основном итеративность: главная работа — переделка уже сделанной отправки по обратной связи, а статусы «доставлено» и «прочитано» — небольшой попутный инкремент. Итерации 4-5 — инкременты: к работающему продукту добавились медиа и голосовые. А решение «видео отложить» — главный выигрыш подхода: по каскадному ТЗ видео сделали бы сразу, потратив бюджет на функцию, которая почти не нужна.
Пример показывает логику решений, а не типичные сроки.
Преимущества
- Ранняя проверка идеи. Первая работающая версия появляется через несколько итераций, и заказчик видит реакцию рынка до того, как потратит весь бюджет.
- Дешевле менять решения. План пересматривается каждую итерацию, поэтому ошибка в требованиях стоит одной-двух итераций, а не всего проекта.
- Ошибки находят раньше. Тестирование идет в каждой итерации, а не одним этапом в конце.
Преимущества работают только при условии: у команды есть доступ к заказчику или пользователям и право менять план. Если обратную связь некому давать, итерации превращаются в формальность.
Риски и как их снижать
«Нагрузка на серверы» и «медленные базы данных», которые иногда приписывают подходу, зависят от архитектуры, а не от процесса. Реальные риски другие.
| Риск | Как проявляется | Что делать |
|---|---|---|
| Размытый объем (scope creep) | Каждая итерация добавляет «еще одну функцию», продукт не выпускается | Цель релиза и критерии готовности, приоритизация бэклога |
| Нефиксированный бюджет и срок | Заказчик не может заранее понять итоговую цену | Фиксировать бюджет и срок, а объем делать переменным; считать стоимость итерации |
| Технический долг | Ранние быстрые решения тормозят следующие итерации | Закладывать время на рефакторинг, пересматривать архитектуру раз в несколько итераций |
| Регрессии | Новая функция ломает старую | Автотесты, непрерывная интеграция, проверка старого поведения в каждой итерации |
Итеративный подход не делает бюджет бесконечным, он меняет то, что фиксируется: в каскаде — объем, из которого считают цену, в итеративной модели — цену и срок, а объем определяют приоритеты.
Спиральная модель — итерации, управляемые рисками
Спиральная модель — вариант итеративного подхода, который описал Барри Боэм (статьи 1986 и 1988 годов). Каждый виток спирали включает постановку целей, анализ рисков и поиск способов их снизить, разработку и планирование следующего витка. После витка решают, продолжать ли проект.
Отличие от обычной итеративной разработки — в том, что определяет содержание витка: главный риск, а не очередная функция. Если главный риск — что устройство не подключится к сети, первый виток — прототип подключения, а не интерфейс. Модель уместна в крупных проектах, где ошибка стоит дороже анализа.
Выводы
- Итеративный подход — это повторение цикла «план — работа — проверка — выводы» с переделкой сделанного; инкрементный — наращивание продукта работающими частями.
- На практике подходы совмещают: итеративно-инкрементная разработка лежит в основе Scrum и других гибких практик.
- От каскада подход отличает ранняя работающая версия, тестирование в каждой итерации и дешевые изменения требований.
- Главные риски — размытый объем, технический долг и регрессии; они снижаются фиксацией бюджета и срока при гибком объеме, автотестами и рефакторингом.
- Спиральная модель — итерации, содержание которых определяет главный риск.
Где применяется / связь с практикой
Итеративный подход — ежедневная работа менеджера проектов: планирование итерации, бэклог, демо заказчику, договор с фиксированным бюджетом и гибким объемом. Как стадии жизненного цикла связаны с версиями продукта от альфы до релиза, разобрано в статье о версиях программ и жизненном цикле ПО.
Освойте тему на практике
Если хочется освоить управление такими проектами системно, с практикой на кейсах, посмотрите курс «Менеджер Agile-проектов». Отдельные темы по управлению разработкой разбирают на открытых уроках Otus.
FAQ
Итеративный подход и Agile — одно и то же?
Нет. Итеративная разработка появилась задолго до Agile-манифеста 2001 года. Agile — набор ценностей и принципов, а итеративно-инкрементный цикл — один из механизмов, на которые эти принципы опираются.
Можно ли работать итерациями при фиксированном ТЗ?
Можно, если ТЗ разбито на части: тогда подход ближе к инкрементному. Выгода меньше, но заказчик раньше получает работающие части и раньше находит ошибки понимания.
Какой длины должна быть итерация?
Единого правила нет. В Scrum спринт не длиннее месяца, чаще 1-2 недели. Короче — быстрее обратная связь, но больше накладных расходов на планирование и демо.
