Итеративная разработка

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

Итеративный процесс — это поэтапное создание программного обеспечения. Его название происходит от слова iteration, что означает «повторение». Итеративный подход также известен как итерационный, эволюционный или инкрементный — это синонимы.

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

Чтобы понять, как работает итерационный метод, можно провести аналогию со строительством дома.

Техническое задание: предположим, клиент хочет трехэтажный особняк с садом и бассейном.

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

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

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

Итерационный метод, он же этапный подход, предлагает совсем иной жизненный цикл проекта:

1. Сначала создают минимально жизнеспособный продукт — также его обозначают английской аббревиатурой MVP. Это рабочая версия ПО с минимальным набором функций. Она нужна, чтобы получить первичный отклик от пользователей и начать формулировать гипотезы насчет дальнейшего развития продукта. В нашем примере на участке, отведенном под особняк, возводят базовую модель жилья — небольшой одноэтажный дом.

Обратная связь и корректировка ТЗ. Клиент заселяется и сообщает подрядчику, что ему нравится и не нравится. Например: «Не нравятся планировка и светлый цвет стен, окна слишком маленькие, а высоту будущего дома хочется снизить до двух этажей».

2. Следующая итерация: подрядчик перекрашивает стены в темный, расширяет оконные проемы, достраивает второй этаж. Обратная связь и корректировка ТЗ. Клиенту нравится дом, он согласовывает дополнительные фичи: сад и бассейн.

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

Представим, как бы шел процесс, если бы строительство велось по каскадной методологии. Подрядчик сразу бы построил дом по изначальному ТЗ: трехэтажный, с узкими окнами и светлыми стенами. Заказчик смог бы внести корректировки только после завершения строительства.

Такой подход увеличил бы сроки и бюджет проекта. Подрядчику пришлось бы:

• сносить третий этаж;
• перекрашивать стены на двух этажах, а не на одном — расходы на краску выросли бы вдвое;
• расширять оконные проемы не на одном, а на двух этажах.

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

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

1. Сбор и анализ требований
   
   Процесс начинается со сбора и анализа требований к продукту. Данные систематизируют и документируют. Выясняют, соответствует ли бюджет заказчика требованиям.
   
2. Проектирование
   
   Разработчики получают полный набор требований к ПО и предлагают решения для достижения результата. Создают дизайн и архитектуру продукта, определяют уровень сложности и критичность проекта.
   
3. Разработка
   
   Команда пишет код, создает функции ПО для итерации. Сверяет результат с изначальными требованиями. Создает продукт, готовый к установке и запуску.
   
4. Тестирование
   
   Процесс тестирования нужен, чтобы выявить проблемы и ошибки. Их оперативно устраняют.
   
5. Развертывание
   
   ПО разворачивают в рабочей среде. Собирают отклики у пользователей.
   
6. Обзор
   
   Команда и клиент изучают результат. Проверяют, соответствует ли он требованиям. Если надо, вносят улучшения. Решают, использовать ли готовую версию ПО как базу для следующей итерации. Определяют, была ли итеративность эффективна, или в следующий раз лучше выбрать другой подход для похожего продукта.

• Разработка ведется по принципам Agile.
• У заказчика нет четкого видения конечного продукта, определены только основные требования.
• Заказчик приходит с четким видением продукта, но неоднократно меняет ТЗ после начала разработки.
• Непонятно, какими функциями продукта люди будут пользоваться, а какими — нет.
• Идет разработка инвестиционного проекта, условия финансирования которого могут неожиданно измениться.
• Команда действует итеративно, чтобы изучать и сразу применять новую технологию.

• Выделен бюджет, который нельзя превышать.
• Есть четкие сроки, в которые продукт должен быть полностью готов.
• Дано подробное ТЗ на разработку, отклоняться от которого можно лишь незначительно.
• Заказчик не готов сильно вовлекаться в процесс, а хочет дать задание и получить результат.

• Эта модель позволяет разработчикам опираться на опыт, полученный из предыдущих итераций. Чем дольше процесс, тем больше специфических знаний и навыков накапливает команда.
• Итеративный способ не требует создания исчерпывающего ТЗ. Чтобы разработка началась, достаточно предоставить ТЗ для базовой версии ПО. ТЗ для второй итерации можно готовить, пока для первой пишут код.
• Подход не дает рискам перерасти в критические. Их устраняют, как только обнаружат небольшой изъян.
• Этот подход повышает эффективность общения с аудиторией. Разработчики быстро получают обратную связь и вносят изменения в продукт. Пользователи довольны, подрядчику удобно корректировать код по горячим следам.
• Итеративный метод дает возможность выделить приоритетные функции на любом этапе и сосредоточиться на них. Это важно, если разработка отошла далеко от первоначального ТЗ. Не надо ждать, пока продукт закончат полностью.
• Итеративный принцип — шанс снизить затраты. Разработка может обойтись дешевле, потому что баги выявляют и правят на ранней стадии. Обратная связь от пользователей позволяет понять, какие функции ПО не востребованы, и не вкладываться в их развитие.
• Такой подход повышает качество продукта. Регулярно выходят новые версии ПО, каждая лучше предыдущей. Когда финальный результат работы готов, в нем почти нет багов. Ошибки нашли и исправили, пока шел поэтапный процесс совершенствования продукта.
• Итеративный принцип ускоряет выход на рынок. Разработчики могут одновременно улучшать несколько разных элементов ПО. Не надо ждать, пока одна часть команды закончит свои задачи и передаст эстафету коллегам.
• Продукт выходит на рынок максимально быстро. Итерационный принцип позволяет клиенту зарабатывать на MVP и вкладывать деньги в процесс совершенствования товара.

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

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

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

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

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