Определение длительности итерации

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

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

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

Пример:

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

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

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

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

В таблице приведены некоторые опытные данные:

• Итерации продолжительностью более 6 месяцев скорее всего потребуют установления промежуточных вех, которые позволят вести проект более эффективно. Рекомендуется ограничить объем итерации, чтобы сократить ее сроки и более четко обозначить ее цели.
• Итерации продолжительностью более 12 месяцев рискованны еще и тем, что они переходят в другой финансовый год. Если проект не дает видимых результатов в течение 12 месяцев, он рискует лишиться финансирования.
• Итерации продолжительностью менее 1 месяца должны иметь четко обозначенную область. Как правило, краткие итерации лучше всего подходят для этапа построения, когда добавляется минимум новых функций и степень новизны невелика. В кратких итерациях не требуется подробный формальный анализ или проектирование, и они могут быть посвящены постепенному улучшению уже хорошо обозначенных функций.
• Итерации могут иметь разную продолжительность: она варьируется в зависимости от целей. Как правило, итерации на этапе уточнения будут длиться дольше, чем итерации при построении. В рамках одного этапа лучше делать одинаковые по продолжительности итерации, это упрощает планирование.

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

Пример Итерации для внутреннего телефонного коммутатора

• Итерация 1: локальный звонок.
• Итерация 2: внешние звонки и управление подписчиками.
• Итерация 3: голосовая почта и конференции.

Определение числа итераций

В очень простом проекте можно ограничиться одной итерацией на каждом из этапов.

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

Для более объемного проекта разработка будет вестись следующим образом:

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

Для большого проекта с рядом новых и неопробованных технологий схема может быть следующей:

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

Итак, цикл разработки может быть следующим:

• Простая система: 3 итерации [0,1,1,1]
• Типичная система: 6 [1, 2, 2, 1]
• Сложная система: 9 [1, 3, 3, 2]
• Очень сложная система: 10 [2, 3, 3, 2]

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

Риски, объем и сложность проекта могут вносить свои коррективы:

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

Сопоставление обзоров в традиционной водопадной последовательности с итеративным подходом

В проекте, разрабатываемом по методу водопада, в конце каждой стадии проводится критический обзор создаваемых рабочих продуктов, а именно:

• Обзор требований к системе (SRR), по завершении выработки спецификаций системы
• Обзор спецификации программного обеспечения (SSR), по завершении выработки спецификации требований к программному обеспечению
• Обзор предварительного проекта (PDR), по завершении выработки разделов по архитектурному проекту описания проекта программного обеспечения
• Критический обзор проекта (CDR), по завершении детализации разделов по проекту описания проекта программного обеспечения.

В Rational Unified Process (RUP) обзор компонентов соответствующих рабочих продуктов проводится по их завершении в итерации, но вехи (и обзор, соответственно,) планируются на окончание четырех этапов, начального, уточнения, построения и внедрения. Руководитель проекта, желающий применять RUP, может столкнуться с необходимостью сгладить этот конфликт, возникающий, например, из-за обязательств по контракту. В идеале руководитель проекта должен попытаться убедить заказчика в том, что подход на основе этапов и итераций дает большую прозрачность хода проекта и снижает риски, вследствие чего отпадает необходимость в SRR, SSR и пр. Однако это не всегда возможно, и тогда руководитель проекта должен запланировать время для таких обзоров. В RUP можно указать моменты, в которые эти важные рабочие продукты, точнее говоря, их эквиваленты в RUP, оказываются фактически завершенными, хотя это не всегда совпадает с этапами или итерациями.

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

• SRR (в основном это касается видения) планируется в конце начального этапа
• SSR (затрагивает спецификацию требований к программному обеспечению) - примерно 1/3 этапа уточнения
• PDR (касается документа архитектуры программного обеспечения) - в конце этапа уточнения
• CDR (затрагивает проектную модель ) - примерно 1/3 этапа построения

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

Организация проекта

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

• контекст бизнеса
• объем усилий по разработке программного обеспечения
• новизна
• тип приложения
• текущий процесс разработки
• организационные факторы
• сложность технологии и управления

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

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

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

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

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

Принципы построения структуры организации подробно описаны в [ROY98]. В особенности при распределении обязанностей в группе оценки программного обеспечения следует помнить, что эта группа будет работать с программным обеспечением в наиболее приближенной к ситуации реального пользователя обстановке.

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

На каждом этапе в ходе проекта на передний план выступают определенные группы задач:

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

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