Измерение ПО позволяет проникнуть в суть проекта, продуктов и процессов более точно, чем если опираться на субъективные впечатления или неясные воспоминания о прошлом опыте. При выборе показателей следует опираться на вопросы, на которые вы или менеджеры пытаетесь найти ответы, а также на цели, которых вы пытаетесь достичь. Измерение активности изменений — это способ оценки стабильности требований. Он позволяет также обнаружить возможности для улучшения процесса, чтобы снизить количество изменений в будущем.
Возможно, вам следует контролировать следующие показатели активности изменений (Раulk и др., 1995):
· количество полученных запросов на изменение, открытых и закрытых в настоящее время;
· общее число пришедших запросов, включая добавленные, удаленные и измененные требования (вы также можете подсчитать этот показатель как процент от общего количества требований в базовой версии);
· количество полученных запросов на изменение, исходящих из каждого источника;
· количество изменений, предложенных и внесенных в каждое требование после создания базовой версии;
· общие усилия на обработку и реализацию запросов на изменение; количество циклов процесса изменений, необходимых для должной реализации каждого утвержденного изменения (иногда изменения реализуются неправильно или являются причиной появления других ошибок, которые необходимо исправить).
Вам не обязательно настолько тщательно отслеживать этапы изменения требований. Как и в случае с показателями ПО, необходимо до принятия решения о том, что именно вы будете измерять, четко понять цель измерения и то, как вы будете использовать полученные данные (Wiegers, 1999a). Начните с простых параметров, чтобы выработать культуру измерения в вашей организации и собрать ключевые данные, необходимые для эффективного управления проектами. По мере наработки опыта усложняйте ваши измерения, насколько это необходимо для успеха проекта.
|
|
На рис. 19-3 показан один из способов контроля количества изменений требований в ходе разработки проекта. Здесь отслеживается скорость появления предложения об изменении требований. Точно так же контролируется и количество утвержденных запросов на изменение. Не подсчитывайте изменения, внесенные до составления базовой версии; вы знаете, что в этот период требования все еще развиваются. Однако после создания базовой версии все изменения должны приниматься в соответствии с процессом контроля изменений. Вам также следует проследить частоту изменений (изменчивость требований). Кривая на этом графике должна стремиться к нулю по мере приближения даты поставки. Высокая частота в течение длительного времени свидетельствует о том, что возможно нарушение расписания поставки продукта. Вероятна и другая причина: первоначальная базовая версия требований была неполной, то есть следует улучшить подход к сбору информации по требованиям.
Рис. 19-3. Пример графика активности изменения требований
Рис. 19-4. Пример графика, демонстрирующего источники изменения требований
Менеджер проекта, обеспокоенный тем, что частые изменения помешают своевременному завершению проекта, может собрать дополнительную информацию, отследив происхождение изменения требований. На рис. 19-4 показан способ представления количества запросов на изменение, пришедших из разных источников. Менеджеру проекта стоит обсудить такой график с менеджером по маркетингу, так как большинство изменений запрошено именно отделом маркетинга. Плодотворная дискуссия позволит установить, какие действия должна предпринять команда, чтобы уменьшить число изменений, полученных после создания базовой версии из отдела маркетинга. Использование данных в качестве отправной точки для такой дискуссии гораздо продуктивнее встречи противоборствующих сторон, основанной на взаимном раздражении.
|
|