5.6.5. Отслеживание проекта

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

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

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

При подготовке списка невыполненных работ по продукту для следующего спринта владелец продукта выполняет следующие действия.

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

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

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

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

Отслеживание хода подготовки к выпуску

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

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

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

Visual Studio ALM предоставляет несколько отчетов, которые помогут командам отслеживать ход выполнения в течение нескольких спринтов.

Отчет "Состояние всех итераций" (гибкая разработка)

Отчет "Обзор описаний функциональности" (гибкая разработка)

Отчет "Ход выполнения описаний функциональности" (гибкая разработка)

Можно создавать настраиваемые отчеты и запросы рабочих элементов для отслеживания хода выполнения работ.Дополнительные сведения см. в разделах Создание и настройка отчетов для Visual Studio ALM, а также управление ими и Поиск ошибок, задач и прочих рабочих элементов.

Завершение выпуска

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

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

Нормативное руководство по CMMI для разработчиков опубликовано институтом Software Engineering Institute под названием "CMMI: Guidelines for Process Integration and Product Improvement." В этой работе подробно описана интеграция CMMI для разработки (CMMI-DEV) версии 1.2, представляющая собой одну из моделей в составе пакета продуктов CMMI на момент создания этого материала. Данная модель отличается высокой стабильностью и, вероятно, сохранит свою актуальность надолго. Существует еще одна полезная и доступная работа по этой теме — "CMMI Distilled: A Practical Introduction to Integrated Process Improvement". Дополнительные сведения об этих книгах см. в подразделе Дополнительные ресурсы далее в этом разделе.

5.7.CMMI

CMMI появилась в 1987 году как развитие методологии CMM, которая разрабатывалась научно-исследовательским центром Software Engineering Institute в университете Карнеги-Меллона. Этот центр был создан и финансировался на средства Министерства обороны США. Модель CMM for Software была впервые опубликована в 1991 году и основана на контрольном списке критически важных факторов успеха проектов по разработке программного обеспечения в конце 70-х и начале 80-х годов. Значительный вклад в развитие модели внесли специалисты по научным исследованиям корпорации IBM и ведущие эксперты по контролю качества 20-го века Филипп Кросби и У. Эдвард Деминг. Модель зрелости производственных процессов (Manufacturing Maturity Model), созданная Кросби, легла в основу пяти уровней поэтапного представления (см. далее в этом разделе) и дала имя модели зрелости процессов создания ПО (Capability Maturity Model). CMM использовалась в основном при реализации оборонных программ, прошла несколько редакций и итераций и теперь имеет довольно широкую область применения. Успех модели привел к разработке моделей CMM для других сфер деятельности, не связанных с программным обеспечением. Увеличение числа моделей вызывало путаницу, поэтому правительство профинансировало двухлетний проект с участием более 200 экспертов из области промышленности и науки с целью создания единой, расширяемой платформы, способно интегрировать системное проектирование, программное проектирование и разработку продуктов. В результате была создана модель CMMI.

Прежде всего, необходимо уяснить, что CMMI-DEV — это модель. Это не процедура или инструкция к действию. Это набор организационных поведений доказанной эффективности при разработке программного обеспечения и системном проектировании. Зачем использовать эту модель? Какова ее цель? Как лучше ее использовать? Это важнейшие вопросы о CMMI, вызывающие больше всего споров.

Зачем использовать эту модель?

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

• Предоставляет общую платформу и язык для взаимодействия.

• Основана на многолетнем опыте.

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

• Пользуется поддержкой тренеров и консультантов.

• Может служить стандартом для разрешения противоречий.