Итерационная модель разработки - процесс проектирования и реализации кода продукта, при котором не вносятся серьёзные изменения в архитектуру, а лишь направляются эволюционные процессы развития. Вот так вот мудрёно я завернул. Скукотища? =) Читайте дальше, ещё не такое увидите!

Довольно распространённая ошибка начинающих разработчиков (а именно к ним и направлены мои посты) - попытка объять необъятное - продумать и реализовать весь проект сразу, с одной попытки и за один проход. С полной уверенностью заявляю: это невозможно! Будьте гибче, разрабатывайте проект частями.

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

Итерационная модель разработки применяется для упрощения ведения проекта. Давайте рассмотрим это на примере. Допустим, Вам нужно написать систему сбора и анализа статистики. Довольно типовая задача, верно?

Конечно же, хочется замахнуться на глобальную, уникальную, универсальную (маниакальную и прочие -альную) систему, которая будет уметь в зависимости от переданного пресета настроек и входных файлов формировать различные отчёты с применением статистических методов анализа, а также рисовать красивые графики и - чего доброго! - прогнозировать! Уверяю Вас, сколько бы Вы ни сидели с UML-библией, бумагой, ручкой и кружкой чая, всё равно до конца продумать систему такого уровня не получится. Кстати говоря, живую реализацию такого уровня я ещё нигде не встречал, может быть, кто-то укажет мне на неё? Буду признателен…

Разработку в таком случае нужно вести аккуратно, по пути эволюционному, итерационно. Шаг за шагом. Сформулируйте минимальные требования к рабочей системе. Обращаю Ваше внимание, нужно постоянно видеть перед собой цель и не плодить мёртвый код! Как только требования определены, реализуйте код, будьте предельно сдержанны, побольше комментариев к коду. После завершения цикла (микроцикла, если Вам угодно), проведите анализ выполненной работы, сопоставьте текущее направление разработки с конечными целями, скорректируйте дальнейшие действия.

Код при таком подходе должен постоянно меняться, улучшаться, эволюционировать. Не бойтесь отсекать лишнее - это всего-лишь код, но он может стать раковой опухолью. Итерационная разработка очень плотно связана с профилированием кода, написание же Unit Test’ов затруднено из-за высокого полиморфизма архитектуры во времени. Не забывайте, что один из главных постулатов эволюции - усложнение структурных образований за счёт деления и мутаций. Меня могут побить биологи, но для кода это совершенно справедливо. Усложняясь, функции (ну и конечно же модули, классы, группы классов) должны делиться, с умом разграничивая свой функционал между наследниками. Самое главное - не отпустить их жить своей жизнью. Постоянно направляйте их развитие в сторону глобальной конечной цели. К сожалению многие OpenSource разработчики (да и “проприетарные” тоже) уводят свои продукты далеко в сторону от первоначальной идеи, и тут появляются fork’и. =)

Вернёмся к микроциклам. Их длина может варьироваться от 2-3 часов до 2-3 дней. Оптимальным интервалом является 4-8 часовой микроцикл (половина, либо полный рабочий день). За это время должна быть сформирована задача, найден подход (довольно просто: он сам должен “родиться”), реализовано решение и подведены итоги, желательно с отчётом (строчки в лог-файл проекта будет достаточно).

Какой бы эта модель разработки Вам не представлялась, у неё есть серьёзный минус: затруднена смена (частичная или полная) архитектуры проекта. Дорогу нужно выбирать в начале пути. Главным плюсом могу назвать готовность системы выполнять свои функции (путь и частично) практически с самого начала разработки.

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