Хорошая метрика обладает следующими основными характеристиками:.
1.
Она имеет смысл для заказчика, менеджера и исполнителя. Если хотя бы одна из заинтересованных сторон не рассматривает метрику как осмысленную, она не будет использоваться. «Покупатель всегда прав» — это девиз торговли, а не догмат разработки. Заказчики обращаются к разработчикам, поскольку те — в отличие от заказчиков — являются экспертами в области разработки и управления проектами ПО. Заказчики должны принимать те метрики, которые будут иметь смысл для разработчика.
2.
Она показывает количественную корреляцию между изменениями в процессе и ходом бизнеса. Единственными реальными целями и задачами организации являются финансовые: снижение затрат, повышение доходов и увеличение прибыли.
3.
Она объективна, и ее определение недвусмысленно. Объективность следует трансформировать в некоторую форму числового представления (например, цифры, проценты, доли) в противоположность представлению текстовому (например, отличный, хороший, правильный, плохой). Неопределенность минимизируется посредством использования понятных единиц измерения (таких, как человеко-месяцы, SLOC, изменения, функциональные точки, классы, сценарии, требования), которые не так просто определить точно.
4.
Она показывает тенденции. Это очень важная характеристика. Понимание изменений значения метрики в зависимости от времени, от проекта к проекту, от версии к версии и т.д. оказывается чрезвычайно важным, особенно для современных моделей итерационной разработки. Редко случается, чтобы некоторая метрика напрямую приводила к выполнению каких-либо конкретных действий. Скорее, метрика представляет взгляд с некоторой точки зрения. И интерпретировать эту метрику, и определить, какие действия необходимы, является задачей тех, кто ответственен за принятие решений (менеджера, команды или иной структуры, занимающейся обработкой информации).
5.
Она является естественным побочным продуктом процесса. Ради метрики не добавляются новые рабочие продукты или дополнительные виды деятельности; она выводится непосредственно из самих рабочих процессов.
6. Она может быть автоматизирована. Опыт показывает, что наиболее удачными метриками являются те, информация о которых собирается и представляется автоматически. Отчасти это так, потому что программный инструментарий требует строгих определений для обрабатываемых данных.
Когда метрики указывают на некоторую проблему, важно вникнуть во все симптомы, чтобы поставить диагноз. Метрики обычно отображают эффекты; для понимания причин необходим синтез многих точек зрения и умозаключений. Например, умозаключения необходимы для правильной интерпретации следующих ситуаций:.
■ Малое количество запросов на внесение измекений может означать, что ПО совершенно и свободно от ошибок, а может означать то, что команда, ответственная за тестирование, находится в отпуске.
■ Запрос на внесение изменений, который остается открытым в течение длительного времени, может означать, что ошибка была легко диагностирована, но ее исправление потребовало значительных доработок, либо может означать, что ее диагностика заняла очень много времени, а исправление заключалось во внесении изменений в одну единственную строку кода.
■ Большой рост персонала в текущем месяце может привести к пропорциональному увеличению прогресса, если новый персонал состоит из обученных людей, которые сразу же приступят к производительному труду. И он же может вызвать замедление прогресса, если наняты необученные люди, которым потребуется самая разнообразная поддержка со стороны тех, кто занят производительным трудом, для ввода в курс дела.
Качественные оценки не могут выполняться самими метриками, для этого требуются интеллектуальные усилия со стороны, например, менеджеров проектов по созданию ПО.