Поделиться через

Действия в рамках итерации

  • Статья

В MSF for CMMI Process Improvement v5.0 проект планируется в виде ряда итераций. Каждая итерация длится обычно от четырех до шести недель, в течение которых команда разработчиков реализует заданный набор требований.

Начало итерации

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

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

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

  • Задайте для каждой задачи значение поля "Исходная оценка". Разделите на части задачи, оценки времени выполнения которых превышают несколько дней.

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

Дополнительные сведения см. в разделе Планирование итерации (CMMI).

Ход итерации

Выполнение задач

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

Если какой-либо участник команды сталкивается в своей работе с тем или иным препятствием, которое невозможно устранить немедленно, он должен зарегистрировать рабочий элемент "проблема". Дополнительные сведения см. в разделе Проблема (CMMI).

Тесты

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

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

Непрерывные и ночные построения

Система построения производит построение продукта на основе недавно проверенных обновлений и выполняет автоматические тесты. Можно задать основные тесты для выполнения на непрерывной основе и полный набор для выполнения каждую ночь. В результате многочисленные приращения не будут приводить к накоплению ошибок. Дополнительные сведения см. в разделе Администрирование Team Foundation Build.

Летучки

Вся команда проводит краткий ежедневный анализ хода выполнения задач итерации. Участники команды могут представлять панель мониторинга хода выполнения на стене, совместно использовать ее с помощью Office Live Meeting или делать то и другое. Дополнительные сведения см. в разделе Панель мониторинга хода выполнения (CMMI).

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

  • Руководитель проекта или руководитель группы сообщает о ходе устранения проблем. Дополнительные сведения см. в разделе Управление проблемами (CMMI).

  • Анализируется число ошибок. Исправлению ошибок должен быть дан приоритет над новой разработкой. Цель — поддерживать число ошибок на низком уровне в ходе всего проекта. Если число ошибок возрастает, следует обсудить причины и возможное влияние на техническую разработку.

  • Анализируется темп выполнения работ.

Корректировка области

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

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

Запросы на изменения и риски во время итерации не рассматриваются.

Рассмотрение

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

Дополнительные сведения см. в разделе Работа с ошибками.

Конец итерации

Проверка

Требования считаются выполненными, только если прошли все связанные с ними тесты. Дополнительные сведения см. в разделе Проверка требований.

Ретроспектива

Улучшение процесса — важная цель CMMI.

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

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

При внесении в процесс какого-либо изменения следует убедиться, что в команде существует общее мнение по следующим вопросам.

  • Как можно будет выяснить, произошло ли улучшение?

  • Когда будет сделана такая оценка?

  • Что будет сделано в результате?

Интеграция

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

Интеграция состоит из двух основных шагов.

  • Прямая интеграция. Служит для ввода нового кода из главной ветви в локальную ветвь проекта. После выполнения такого слияния выполняются автоматические или ручные тесты. В результате появляются некоторые дефекты. Дефекты устраняются с высоким приоритетом.

  • Обратная интеграция. Код локальной ветви вводится в главную ветвь, и в главной ветви выполняются построение и полный набор тестов. При появлении любых ошибок изменения отменяются. Вводить ошибки в главную ветвь не рекомендуется. Если ошибок не возникает, интеграция объявляется завершенной.

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

Подготовка к следующей интеграции

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

Дополнительные сведения см. в разделе Действия по проекту.