Концепция: Iteration
Итерация - это установленный период времени в пределах проекта, в течение которого создается стабильная работающая версия продукта вместе с соответствующей документацией, установочными скриптами и прочими артефактами, необходимыми для использования данного релиза. Также иногда называется циклом или временным отрезком (timebox).
Взаимосвязи
Основное описание

Что такое итерация

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

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

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

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

Какие проблемы решаются с помощью итераций?

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

Продолжительность итерации

Обычно итерации имеют продолжительность 4 недели, но некоторые команды работают с короткими итерациями в одну неделю, или с длинными итерациями в шесть недель. Факторы, влияющие на продолжительность итерации приведены в таблице X.

Таблица X. Факторы, влияющие на продолжительность итераций.

Факторы, ведущие к уменьшению продолжительности итерации Факторы, ведущие к увеличению продолжительности итерации
Небольшие команды Большие команды
Географически сосредоточенные команды Географически распределенные команды
Сильная система управления конфигурацией Плохая система управления конфигурацией
Выделенные ресурсы на полный рабочий день Ресурсы предоставляются на неполный рабочий день или по матричной схеме
Автоматизированное тестирование Отсутствие автоматизированного тестирования
Интегрированная инструментальная среда Отсутствие хорошей интегрированной и автоматизированной инструментальной среды
Опытная в области итеративной разработки команда Неопытная команда в области итеративной разработки
Быстрое принятие решений Политические и бюрократические препятствия к быстрому принятию решений
Нечеткие требования Понятные требования
Нечеткая или хрупкая архитектура Хорошо определенная и стабильная архитектура
Новая или непонятная технология Хорошо известная технология


Почему итерации нужно использовать?

Итеративный подход в сравнении с методом "водопада" имеет несколько проверенных преимуществ:

  • Больше вероятность того, что вы создадите приложение, отвечающее потребностям пользователя. Если слишком рано начать сбор требований, это часто приводит к неиспользуемым возможностям ПО. Стандиш Груп (Standish Group) провело исследование тысяч проектов по разработки программного обеспечения и обнаружило, что более 45 процентов возможностей никогда не используются, а еще 19 процентов используются редко (см. рисунок 2.3). Другими словами, обычно более половины усилий разработчиков тратится впустую на неважные возможности. Чтобы избежать этой проблемы, необходимо привлечь в процесс разработки заказчика и использовать итеративный подход, позволяющий в каждой итерации реализовывать и проверять те возможности, которые считаются наиболее важными. Такой подход позволяет не только как можно раньше проводить проверку ключевых возможностей, но добавлять новую функциональность на поздних стадиях проекта.
  • Интеграция - это не "большой барабум" в конце проекта. Оставление интеграции на потом приводит к переделкам, отнимающим время и деньги. Чтобы избежать значительных переделок, при итеративном подходе проект разбивается на небольшие итерации, в каждой из которых развивающийся код интегрируется постоянно, что позволяет быстро получать отзывы заинтересованных лиц и минимизировать переделки на поздних стадиях.
  • Риски обычно обнаруживаются и учитываются на первых итерациях проекта. Чтобы быть уверенным, что вы находитесь на правильном пути, реализуйте наиболее важные возможности по частям, и демонстрируйте их основным заинтересованным лицам. Например, если существует риск, что заинтересованное лицо не будет удовлетворено разработанной вами функциональностью, итеративная разработка поможет реализовать наиболее важные возможности по частям, дажный раз демонстрируя результат заинтересованным лицам приверяя, действительно ли  вы находитесь на правильном пути.
  • Вашу способность работать эффективно можно настроить более точно. Во время первых итераций участники команды проходят через все действия жизненного цикла, что позволяет быть уверенным, что в наличии имеется инструментарий, навыки, организационная структура и прочее необходимое для эффективной работы.
  • Руководство имеет возможность вносить в продукт тактические изменения. Руководство может вносить изменения в продукт в любой момент - например, для учета конкуренции с другими продуктами. Руководство может вносить изменения в проект в процессе разработки, к примеру, для конкуренции с другими новыми продуктами. Итеративная разработка позволяет Вам быстро развертывать частные воплощения конечного продукта и использовать их для быстрой реализации продукта меньшей функциональности чтобы противостоять инициативе конкурента.
  • Ускоряется повторное использование. Проще определить общие части в итерациях когда они спроектированы или реализованы частично, чем распознать их вначале. Обсуждения и пересмотры дизайна на ранних итерациях позволяют членам команды освещать потенциальные возможности для повторного использования, и далее, в последующих итерациях, разработать хорошо продуманный общий код, для использования этих возможностей.
  • Дефекты обнаруживаются и исправляются в течении нескольких итераций. Это приводит к получению приложения более высокого качества с более устойчивой архитектурой. Недостатки обнаруживаются на ранних итерациях, а не во время фазы всеобщего тестирования в конце. Узкие места в производительности обнаруживаются тогда, когда их еще можно исправить, а не перед самым выпуском продукта. 
  • Персонал проекта используется лучшим образом. Многие организации соединяют использование методологии "водопада" с конвейером: аналитики отправляют готовые требования проектировщикам, которые отправляют готовый дизайн программистам, которые отправляют компоненты интеграторам, которые отправляют систему тестировщикам. Подобные передачи из рук в руки являются причиной ошибок и взаимонепонимания, и приводят к уменьшению чувства ответственности за конечный продукт. Итеративный процесс поощряет к расширению опыта участников команды, предоставляя им возможность исполнять различные роли, а менеджеру проекта - использовать персонал лучшим образом и устранять проблемы, порождаемые передачей из рук в руки.
  • Участники команды постоянно обучаются. Участники проекта в течение цикла разработки от одной итерации к другой получают возможность учиться на собственных ошибках и улучшать свои навыки. Дополнительный опыт можно извлечь, если проводить оценивание результатов первых итераций проекта.
  • Сам процесс разработки постоянно улучшается и уточняется. При оценивании итерации не только проводится оценка текущего состояния проекта с точки зрения исполнения графика, но и поиск путей улучшения самого процесса разработки. Один из возможных способов этого добиться - хранить ретроспективу проектов.

45 percent of featues implemented are never ever used

Рисунок 2.3. Большая часть реализованной функциональности используется редко или вообще никогда.
45 процентов реализованной функциональности никогда не используется, а еще 19 процентов используется редко. Если отказаться от первоочередной реализации неиспользуемой функциональности, время разработки можно сократить примерно вдвое. Так как обычно производительность измеряется в количестве строк кода или реализованной функциональности, данное улучшение не будет распознаваться как увеличение производительности.

Итерации и фазы

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

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

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