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

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

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

Жизненный цикл проекта при итеративной разработке

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

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

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

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

Сравнение водопадной и итеративной моделей разработки можно метафорически описать на примере разработки некого гипотетического проекта, направленного на создание транспортного средства.

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

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

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

Преимущества и недостатки итеративной модели в разработке программного обеспечения

Преимущества итеративного подхода

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

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

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

Недостатки итеративного подхода

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

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

Итоги и наш опыт

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

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