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

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

При итеративном подходе, например, в принятом компанией IBM процессе Rational Unified Process (сокраще нно RUP), выполняется последовательность шагов, которые называются итерациями. Каждая итерация включает в себя часть (иногда большую) стадий разработки (сбор требований, анализ, проектирование, выполнение и т. д.), показанных на рис. 1. Каждая итерация имеет четко определённый набор целей, а ее завершение обеспечивает частичную рабочую версию конечной системы. Каждая очередная итерация строится на основе предыдущих итераций, далее развивает, уточняет и совершенствует систему до завершения конечного продукта.

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

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

Итеративный подход имеет преимущества над каскадным подходом по ряду следующих причин.

• Он позволяет учитывать изменяющиеся требования. Изменение требований, добавление функций по требованиям технологии или заказчика – это всегда было главным источником трудностей при выполнении проектов, из-за чего задерживались сроки завершения, разочаровывались заказчики, приходили в отчаяние разработчики. Чтобы избежать таких проблем, группы разработчиков, применяющие итеративный подход, стремятся в первые же недели создать и продемонстрировать заказчику работающее программное обеспечение, чтобы уточнить требования и лучше вникнуть в суть дела.
• Интеграция перестает быть авралом в конце проекта. Откладывание интеграции до конца проекта почти всегда приводит к дополнительным затратам времени на переделку, иногда до 40% от всего времени проекта. Чтобы избежать этого, каждая итерация обязательно заканчивается интеграцией компоновочных блоков, что минимизирует в будущем затраты на переделку.
• Первые итерации выявляют риски. Итеративный подход помогает группе разработчиков уменьшить риски на первых итерациях, на которых выполняется тестирование всех компонентов процесса. Поскольку в каждую итерацию вовлечено много аспектов проекта (инструменты, готовое программное обеспечение, квалификация членов группы разработчиков и т. д.), группа имеет возможность быстро понять, насколько реальны предполагавшиеся риски, и выявить новые риски, о которых ранее не подозревали, причем сделать это еще на ранней стадии, когда проблемы можно устранить относительно легко и дешево.
• Руководство может вносить в продукт тактические изменения. При итеративной разработке быстро создается действующая архитектура (хотя и с ограниченным набором функций), которая может быть легко преобразована в «облегченную» или «модифицированную» версию продукта с целью опередить конкурентов.
• Упрощается выявление общих участков кода. Общие участки кода легче выявить не на стадии планирования, а когда они частично спроектированы или уже написаны при очередной итерации. Анализ плана проекта на первых итерациях позволяет архитектору найти потенциальные возможности, которые могут использоваться различными компонентами системы, а затем разработать и дорабатывать общий код этих возможностей во время последующих итераций.
• За несколько итераций можно найти и устранить дефекты. В результате достигается надежная архитектура и высокое качество приложения. Дефекты можно обнаружить уже на ранних итерациях, а не на фазе массового тестирования в конце проекта. Кроме того, на первых итерациях можно найти узкие места, ограничивающие быстродействие, которые легче исправить на ранней стадии, не нарушая графика проекта и не создавая паники накануне срока поставки.
• Лучше организована работа участвующих в проекте сотрудников. Многие организации, применяющие каскадный подход, работают по конвейерной схеме: аналитик передает составленные им требования проектировщикам, те в свою очередь передают составленный ими план проекта программистам, те передают компоненты интеграторам, а далее система передается на тестирование. При этих передачах происходят ошибки, но беда не только в этом – сотрудники не чувствуют особой личной ответственности за конечный продукт. А при итеративном процессе сотрудники имеют более разнообразные обязанности, и выполняют много ролей. Руководитель проекта имеет возможность более эффективно загружать работой своих сотрудников и устранять риски при передаче материалов от одной ступени к другой.
• Члены группы постоянно учатся. При итеративном процессе разработки есть много возможностей исправлять свои ошибки и повышать свою квалификацию от одной итерации к другой. Оценивая очередную итерацию, руководитель проект может найти возможности обучить членов группы полезным навыкам. В каскадных проектах дело обстоит иначе – каждый узкий специалист занят только своим делом – проектированием, написанием кода или тестированием.
• Процесс разработки можно совершенствовать на протяжении всего проекта. Оценки результатов очередной итерации не только показывают состояние проекта с точки зрения готовности продукта или выполнения графика работ, но также помогают руководителям понять, как улучшить организацию и процесс следующей итерации.

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