“Вы не можете контролировать то, что не можете измерить”.
Том ДеМарко
Благодаря распространению позитивистской научной методологии, считается, что количественные методы способны дать строго объективные, валидные, надежные и структурированные данные. Они активно применяются в различных областях научного знания, поэтому неудивительно, что подобные методы были перенесены и в разработку программного обеспечения. Своеобразным результатом этого переноса являются метрики программного обеспечения. Метрики программного обеспечения (англ. software metric) – искусственно введенная численная мера, позволяющая выделить и оценить определенные свойства программного обеспечения либо его спецификаций.
“Существуют три вида лжи: ложь, наглая ложь и статистика”.
Бенджамин Дизраэли
Существует множество различных классификаций, трактующих метрики с различных позиций и ранжирующих одни и те же характеристики по различным критериям, в результате чего те же самые метрики могут группироваться по-разному. Более-менее универсальной классификацией метрик может считаться их разделение на:
- метрики оценки программного обеспечения;
- метрики оценки условий разработки программного обеспечения.
В каждой из этих категорий могут использоваться метрики с разными шкалами оценки свойств программного обеспечения: номинальной, порядковой, интервальной и относительной.
Номинальная шкала показывают наличие либо отсутствие у программного обеспечения какого-либо свойства.
Порядковой шкале соответствуют метрики, служащие для ранжирования определенных характеристик с помощью сравнения с некоторыми опорными значениями. Измерения по этой шкале по факту показывают взаиморасположение конкретных программ.
Интервальная шкала показывает уже не только взаиморасположение программ, но и то, насколько далеко они отстоят друг от друга.
Относительная шкала позволяет не только разместить программы определенным образом и оценить их размещение относительно друг друга, но также может показать, насколько далеко оценки отстоят от точки, начиная с которой характеристика вообще может быть измерена.
По своему назначению выделяется три типа метрик:
- прогнозирующие;
- диагностические;
- ретроспективные.
Несложно догадаться, что первые нужны, чтобы попытаться предсказать те проблемы, с которыми может столкнуться проект. Вторые служат для мониторинга текущего состояния проекта. Третьи в идеале помогают избежать в будущем тех неприятностей, с которыми команда сталкивалась в текущих или уже завершенных проектах.
Прогнозирующие метрики могут описывать множество различных параметров: предполагаемый объем работ, запланированный бюджет, фактор сложности проекта, сложность плана проекта, количество людских ресурсов, суммарный запас времени и т.д. При этом желательно иметь значения этих показателей для других проектов этого же профиля, чтобы иметь возможность для сравнения. Значительные различия в показателях схожих проектов часто указывают на проблемы. Наверное, если запланированные бюджеты двух очень похожих проектов отличаются на несколько порядков, то это повод задуматься!
Параметров, которые описываются диагностическими метриками, также может быть великое множество. Это и соотношение планового бюджета выполненных работ к фактическому, и соотношение плановых трудозатрат к фактическим, и производительность труда работников, занятых на проекте, и показатели качества, и еще много-много чего еще. Какой бы параметр не измерялся, важно чтобы его измерения происходили регулярно. Форма представления метрик особой роли не играет: кто-то предпочитает табличный вид, а кому-то больше нравятся графики.
По сути, ретроспективные метрики описывают все те же параметры, что и диагностические. Единственная разница между ними лишь в цели использования: если диагностические метрики нужны для оценки текущей ситуации на проекте и реагирования на актуальные проблемы, то ретроспективные помогают оценить уже прошедшие события. Такой ретроспективный анализ позволяет избежать типовых ошибок в будущем.
Таким образом, использование метрик позволяет эффективно управлять проектом: своевременно обнаруживать недостатки, устранять их и при этом видеть, насколько хорошо работают найденные методы решения проблем.
Однако использование метрик сопряжено с определенными сложностями.
Во-первых, ни одна из известных на сегодняшний день метрик не может похвастаться достаточной значимостью и точностью. Метрики не дают объективной картины происходящего, они всего лишь предоставляют некоторые показатели, вычисленные по заданному алгоритму. Особенно это касается тех случаев, когда для оценки какого-либо параметра вводится только одна метрика. Более-менее полную картину может дать только использование целого комплекса метрик,
Во-вторых, часто, если сотрудники знают об измеряемых показателях, то они стараются не выполнить свою работу надлежащим образом, а занимаются подгонкой своих показателей под заданные параметры.
К примеру, если важным показателем является KSLOC (количество строк кода), то программисты будут писать «индусский» код, всячески избегая способов его упрощения, сокращающих количество строчек. Другой пример: если показателем эффективности работы программистов и тестировщиков будет количество допущенных и выявленных багов, то очень скоро они договорятся между собой, как «оптимизировать» этот показатель, чтобы это было выгодно обеим сторонам. Ну и еще один пример: если на проекте открыто используется метрика focus factor и если менеджер проекта не является «технарем», то, скорее всего, программисты будут специально завышать оценки по времени, чтобы создать себе своеобразную «подушку тайм-безопасности».
В-третьих, использование метрик порождает целый ряд этических проблем. В частности, если на проекте одновременно вводятся метрики для оценки сотрудников и метрики для оценки деятельности команды в целом, то это может привести к внутренним конфликтам. В попытках «оптимизировать» собственные показатели сотрудники могут «тянуть одеяло на себя» и обвинять в своих неудачах других участников команды. В итоге между личными целями сотрудников и общими целями команды возникают противоречия, команда не срабатывается, и, как следствие, проект оказывается «заваленным».
В-четвертых, сам процесс сбора метрик сопряжен с определенными техническими сложностями. Как правило, для сбора метрик и их интерпретации выделяются особые сотрудники. Если подходить к этим процессам без должной организации (особенно это касается вопросов автоматизации сбора метрик), то существует риск того, что сотрудники просто «утонут» в собранных сведениях. Тогда придется привлекать дополнительных людей, а это прямой путь к излишней бюрократизации и нерациональному расходованию ресурсов. Кроме того, существует риск того, что из-за сбора числовых показателей сотрудники будут отвлекаться от своих непосредственных обязанностей. Конечно, существуют специальные автоматизированные системы для сбора метрик, упрощающие этот процесс, но, так или иначе, к работе с метриками все равно придется привлекать специалиста-человека, которому придется потратить на это определенное время. Более того, на сбор метрик тратится еще и время членов команды, занятой на проекте. И далеко не каждый заказчик согласен это время оплачивать.
Тем не менее, при правильном внедрении и грамотной интерпретации метрики могут стать весьма полезным инструментом для project-менеджеров. Благодаря использованию метрик можно отследить моменты снижения качества разработки, определить его причины и выявить самые сложные участки в системе. Кроме того, числовые показатели способны помочь в планировании затрат ресурсов на дальнейшее развитие разрабатываемого продукта.
Автор благодарит Ирину Петрашкевич за помощь в написании статьи
