Шаблоны итерации

Итерации на начальном этапе

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

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

Итерации на этапе уточнения

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

Итерации на этапах построения и внедрения

К концу этапа уточнения и на этапах построения и внедрения движущим фактором процесса итераций становятся запросы об изменениях продукта (SCO). К таким запросам относятся:

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

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

На этапах построения и внедрения основное внимание уделяется детальной разработке архитектуры и выполнению остальных требований.

Стратегии итерации

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

Общая/поверхностная проработка

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

Стратегия общей/поверхностной проработки применяется в следующих случаях:

• Участники проекта не обладают достаточным опытом в области данной проблемы или в технической части (включая методологию и процесс).
• Одно из ключевых требований - создание звуковой архитектуры, не имеющей аналогов.

Недостатки стратегии:

• Участники проекта могут поддаться параличу анализа (беспочвенному чувству, что если проект хоть в чем-то несовершенен, реализация не будет иметь успеха).
• Положительные результаты на первых стадиях способствуют укреплению веры участников проекта в свои возможности. Чем больше времени проходит, прежде чем разработчики создают работоспособную модель, тем меньше у них остается уверенности, что они способны достичь успеха.
• Вырабатывается недостаточно полное техническое представление архитектуры, чтобы можно было оценить реальные технические риски.

Узкая/детальная проработка

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

Стратегия узкой/детальной проработки применяется в следующих случаях:

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

Недостатки стратегии:

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

Наблюдения, полученные после длительной работы с итерационным методом

Обычно первые итерации больше основаны на принципах общей/поверхностной проработки, а в более поздних итерациях (когда разработана стабильная архитектура) проводится узкая/детальная проработка.

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

Применение стратегий на разных этапах

• Применение стратегии узкой/детальной проработки на начальном этапе

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

• Применение стратегии общей/поверхностной проработки на начальном этапе

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

• Применение стратегии общей/поверхностной проработки на этапе уточнения

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

• Применение стратегии узкой/детальной проработки на этапе построения

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

Замечания для недавно созданных групп участников

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

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

Запланированные исправления

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

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

• Начальный этап - 40%-100%. Здесь можно разрабатывать пробные, полностью заменяемые прототипы.
• Уточнение - 25%-60% при ранних итерациях; менее 25% при поздних итерациях или циклах эволюции.
• Построение - после создания контрольной версии архитектуры, от 10 и менее процентов за одну итерацию и 25% за все итерации.
• Внедрение - менее 5%.

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

• Очень плотное расписание.
• Проведено недостаточно тестирований или оценок.
• Недостаток мотивации или поверхностное отношение к работе.
• Участники негативно относятся к исправлениям, считая их пустой тратой ресурсов или признаком некомпетентности или неудачи.

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

Обратите внимание, что к изменениям не относятся задачи, которые были вынесены за рамки предыдущей итерации и включены в следующую из-за ограниченности времени каждой итерации. Руководитель проекта должен включить такие задачи в общий список, из которого будут выбираться задачи для следующей итерации. Обычно перенесенные из предыдущей итерации задачи необходимо выполнить в первую очередь. Руководитель проекта должен также должен выяснить и проанализировать причины невыполнения всех запланированных целей предыдущей итерации. Мы не рекомендуем обязательно привлекать дополнительную рабочую силу для соблюдения сроков проекта. Однако хронический недостаток специалистов не позволит выполнять масштабные задачи при каждой итерации. Это может привести к утрате инициативы в коллективе и к недовольству заказчика. Выход из этой ситуации можно найти, применив оценочные модели, например, COCOMO II (см. [BOE00]). С каждой итерацией составляется хронология выполненных задач и изменения качества их выполнения. При планировании очередной итерации руководитель проекта должен в первую очередь учитывать результаты предыдущей итерации.

Уровень планирования

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