Управление проектами

Раздел "Управление проектами" руководства MSF для улучшения процессов CMMI позволяет лучше понять управление, планирование и координацию разработки и обслуживания программных продуктов. Дополнительные сведения о CMMI см. в разделе Сведения о CMMI.

Группы областей процессов управления проектами в CMMI включают Планирование проекта, Мониторинг и контроль проекта, Управление соглашениями с поставщиками, Интегрированное управление проектами, Управление рисками и Количественное управление проектами. Все группы, кроме Количественного управления проектами, находятся на 2 или 3 уровне модели. Количественное управление проектами относится к четвертому уровню модели, отражающему использование организациями с высокой степенью зрелости количественных, статистически защитных, объективных данных для принятия решений в сфере управления и достижения положительных, предсказуемых результатов проектов.

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

Последовательная разработка

Team Foundation и MSF для шаблона процесса CMMI поддерживает последовательную работу. Последовательная разработка позволяет управлять риском, поставляя наглядные и проверенные программные компоненты после заданных временных интервалов в ходе проекта.

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

• В плане проекта описываются требования к компонентам, которые будут реализованы в ходе каждой итерации. План проекта разрабатывается в ходе начальной (нулевой) итерации и анализируется в начале каждой итерации. План проекта можно просмотреть несколькими способами, например через панель мониторинга проекта. Дополнительные сведения см. в разделах Требование (CMMI) и Панель мониторинга "Проект" (CMMI).

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

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

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

Поэтапная разработка имеет следующие преимущества.

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

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

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

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

Более крупные и мелкие циклы

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

Крупные проекты

Проект, над которым команда работает в течение нескольких итераций, может входить в состав более крупного проекта или программы. Несколько команд могут параллельно работать над крупным проектом. Как правило, в каждой команде от 4 до 16 человек.

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

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

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

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

Темы данного раздела

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

См. также

Основные понятия

MSF для улучшения процесса CMMI