ПРОЦЕСС ПЛАНИРОВАНИЯ ИТЕРАЦИЙ

ПРОЦЕСС ПЛАНИРОВАНИЯ ИТЕРАЦИЙ

До настоящего момента наша дискуссия имела отношение исключительно к тем аспектам определения бюджетов и сроков, которые не зависят от области применения. Еще одно направление планирования касается определения реальной последовательности промежуточных результатов. Планирование содержания и сроков для основных контрольных точек и промежуточных итераций является, вероятно, одной из наиболее значимых форм общего плана по управлению рисками. План последовательных этапов создания весьма важен, поскольку всегда существуют поправки, вносимые в содержание и сроки этих этапов по мере того, как предположения, сделанные на ранних стадиях, превращаются в ясно осознаваемые обстоятельства проекта.
Общая последовательность создания и общие указания по числу итераций, необходимых для каждой стадии, обсуждаются ниже. Итерация обычно означает полную синхронизацию на протяжении выполнения проекта с хорошо организованной глобальной оценкой проекта в целом.
Рис. 10.4. Баланс между различными видами планирования на протяжении жизненного цикла.
Остальные микроитерации, такие как ежемесячные, еженедельные или ежедневные работы, выполняются по мере движения к точкам синхронизации на уровне проекта.
■ Итерации на начальной стадии. Ранние работы по созданию прототипов интегрируют основные компоненты предполагаемой архитектуры и обеспечивают реализуемую основу для детализации критичных вариантов использования системы. Такая основа включает в себя уже существующие компоненты, коммерческие компоненты и прототипы, сделанные на заказ, достаточные для того, чтобы продемонстрировать предполагаемую архитектуру и понимание требований, обеспечивающее создание достоверного бизнес-плана, общей концепции и плана разработки ПО. Крупномасштабные,.
выполняемые на заказ разработки могут потребовать двух итераций для создания приемлемого прототипа, однако для большинства проектов оказывается вполне достаточно одной итерации.
■ Итерации на стадии уточнения. Эти итерации приводят к созданию архитектуры, включая полную основу и инфраструктуру для функционирования системы. По завершении «архитектурной» итерации необходимо продемонстрировать некоторые критичные варианты использования. Среди них: (1) инициализация архитектуры, (2) включение сценария для того, чтобы пропустить через систему поток данных для обработки при самых плохих условиях (например, выполнение транзакций или сценария при пиковой нагрузке) и (3) введение сценария для контроля за прохождением через систему потока управления при самых плохих условиях (например, вариантов использования для восстановления после сбоев). В большинстве проектов для получения приемлемой базовой архитектуры необходимо запланировать две итерации. Для архитектуры, не имеющей прецедентов, может потребоваться несколько дополнительных итераций, в то время как проекты, основанные на устоявшейся схеме архитектуры, смогут, вероятно, обойтись одной итерацией.
■ Итерации на стадии конструирования. Для большинства проектов на стадии конструирования требуются по крайней мере две основные итерации: альфа-версия и бета-версия. В альфа-версию должны быть включены функциональные возможности для всех критичных вариантов использования. Обычно они представляют лишь около 70% от общего объема продукта и выполняются с более низким уровнем качества (производительность и надежность), чем тот, что ожидается в конечном продукте. Бета-версия, как правило, обеспечивает 95% всех возможностей продукта, и в ней достигаются некоторые из наиболее важных характеристик качества. Однако обычно требуется завершить реализацию еще нескольких возможностей, а также улучшить стабильность и производительность для приемки окончательной версии продукта. Хотя для большинства проектов достаточно двух итераций на стадии конструирования, существует много причин, по которым следует добавить одну или две дополнительные итерации для контроля за рисками или оптимизации использования ресурсов.
■ Итерации на стадии ввода в действие. Большинство проектов требует наличия единственной итерации по превращению бета-версии в конечный продукт. Опять-таки может понадобиться огромное количество неформальных маленьких итераций для исправления всех дефектов, для использования в бета-версии результатов, полученных по обратной связи с пользователями, и для повышения производительности. Однако по причине накладных расходов, связанных с полномасштабной передачей продукта пользовательскому сообществу, многие проекты умудряются обходиться одной итерацией между бета-версией и окончательным выпуском продукта.
Общая рекомендация такова, что для большинства проектов потребуется от четырех до девяти итераций. Типичный проект будет состоять из шести итераций и иметь следующий вид:.
■ Одна итерация на начальной стадии: архитектурный прототип.
■ Две итерации на стадии уточнения: архитектурный прототип и базовая архитектура.
■ Две итерации на стадии конструирования: альфа- и бета-версии.
■ Одна итерация на стадии ввода в действие: выпуск продукта.
Проекты, имеющие много прецедентов, с заранее оцределенной архитектурой, либо очень небольшие проекты могут обходиться одной итерацией на начальной стадии, объединенной со стадией уточнения; в результате для выпуска продукта используется всего лишь четыре итерации. Очень большой проект либо проект, не имеющий прецедентов, с участием множества заинтересованных сторон может потребовать одной дополнительной итерации на начальной стадии и двух дополнительных итераций на стадии конструирования, что в сумме составит девять итераций. Связанные с этим накладные расходы могут оказаться вполне разумной платой за уверенность в надлежащем управлении рисками и в согласовании действий всех заинтересованных сторон.

Популярные статьи

Свежие статьи