Книга: Искусство управления IT-проектами

Полезные показатели при работе над ошибками

Полезные показатели при работе над ошибками

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

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

 Соотношение обнаруженных ошибок к принятым. Сколько новых только что обнаруженных ошибок требуется исправить, не являются ли они дубликатами других ошибок? Не относятся ли они к ошибкам с приоритетами 3 и 4? Знание соотношения обнаруженных и классифицированных ошибок помогает сделать грубые прикидки относительно неклассифицированных ошибок. Как правило, «качество» ошибок со временем должно снижаться: соотношение «хороших» ошибок, имеющих приоритеты 1 и 2, должно уменьшиться. Примерный темп поступления обнаруживаемых ошибок не сможет подсказать, когда именно это сможет произойти.

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

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

 Коэффициент ответных отказов. Вейнберг (Weinberg) называет темп рецидивов, вызванных исправлением ошибок, коэффициентом ответных отказов (Fault Feedback Ratio, FFR).[97] Если каждая исправленная ошибка вызывает появление двух дополнительных ошибок, коэффициент FFR равен 2,0. Согласно утверждениям Вейнберга, приемлемым коэффициентом является число от 0,1 до 0,3. Если это число больше, значит, качество работы должно быть повышено (и/или снижен темп работы). Многие базы данных ошибок дают возможность связать новые ошибки с уже существующими, позволяя отслеживать показатель FFR. Но я никогда не сталкивался с автоматизацией этого процесса, все строилось на субъективных оценках тех, кто занимался классификацией в масштабе всего проекта. (Учтите, что иногда исправление одной ошибки просто вскрывает существование других ошибок. К FFR это не имеет никакого отношения.)

Оглавление книги