Итеративная разработка программного обеспечения

Итеративная разработка ПО — это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.

Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций, каждая из которых, по сути, является проектом в миниатюре, то есть включает в себя все процессы разработки ПО (сбор и анализ требований, составление спецификаций, непосредственную реализацию, тестирование и запуск), но в рамках одной итерации разрабатывается не весь проект, а только его версия или отдельная часть.

Как правило, цель каждой итерации — это получение версии ПО, включающей в себя как новые или преработанные возможности, реализованные в ходе текущей итерации, так и функциональность всех предыдущих итераций. Результат же финальной итерации содержит всю требуемую функциональность продукта.

Бюджет и сроки, необходимые для реализации финальной версии обычно изначально не устанавливаются, так как не определяется общий объём работ и требования формируются по ходу реализации.

Итеративная, итерационная, инкрементная и эволюционная разработка — фактически, это синонимы.

Итеративность (iteration, «повторение») в данном случае означает подход, основаный на выполнении задач в рамках «мини-проектов», инкрементность (increment «увеличение») означает последовательное добавление функционала к разрабатываемому продукту, а эволюционность (evolutio, «развёртывание») — процесс развития продукта, напоминающий естественное развитие биологических видов.

Водопадная и итеративная модели разработки

Метафорически сравнение водопадной и итеративной моделей разработки часто описывают на примере разработки транспортного средства.

В случае с «водопадом» сначала описываются требуемые характеристики автомобиля, затем по этим требованиям разрабатывается проектная документация. После составления проектной документации собираются отдельные узлы автомобиля и происходит их взаимная интеграция. Результат сборки тестируется на соответствие проектной документации и после этого созданный автомобиль передается заказчику. Все эти этапы занимают достаточно продолжительное время, а пригодный для использования продукт заказчик получает только в самом конце.

В случае с итеративным подходом всё несколько иначе. Изначально ставится задача разработки транспортного средства. И результатом первой итерации может быть вариант такого транспортного средства — например, самокат. Для него не нужен двигатель внутреннего сгорания и собрать его можно в десятки раз быстрее, чем автомобиль. Да, самокат проигрывает автомобилю по очень многим характеристикам, но он всё же более эффективен для передвижения, чем хождение пешком. Результатом второй итерации может быть уже самокат с электродвигателем. На третьей итерации — у самоката могут быть увеличены колеса и он превратится в электровелосипед. На четвертой — электровелосипед может быть оснащён ДВС и станет мотоциклом.

По сути, с каждой итерацией повышаются функциональные возможности. И пока сторонники водопада ждут готовность создаваемого автомобиля, любители итерационного подхода уже пользуются транспортным средством. И вполне может быть, что получившийся в итоге мотоцикл — более правильный бизнес‑результат.

Основные преимущества итеративной модели разработки

Снижение рисков — раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта; большая фокусировка на основных задачах; динамическое формирование требований и управление ими.

Организация эффективной обратной связи проектной команды с потребителем, создание продукта, реально отвечающего его потребностям.

Быстрый выпуск минимально ценного продукта (MVP) и возможность вывести продукт на рынок и начать эксплуатацию гораздо раньше.

Основные недостатки итеративной модели разработки

Проблемы с архитектурой и накладные расходы — при работе с хаотичными требованиями и без проработанного глобального плана архитектура приложения может пострадать, а на её приведение к адекватному виду могут потребоваться дополнительные ресурсы. По сути, за возможность менять требования в ходе создания продукта, приходится так или иначе расплачиваться.

Нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс — для некоторых Заказчиков это неприемлемые условия сотрудничества с разработчиком, им лучше подойдёт водопадная модель.

Резюме

Итеративная разработка отлично подходит для больших проектов, для проектов с неопределенными требованиями и для программных продуктов, которые носят инновационный характер и основаны на бизнес‑гипотезах, требующих проверки.