Здравствуйте, AStarFinder, Вы писали:

ASF>Так и сделано.
Отлично.

G>>Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами.
G>>1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения.
G>>2) Количество написанного кода в lines of code — сравнение с запланированным.
G>>3) График продуктивности LOC/day на закрытых задачах — сравнение с планом.
G>>Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.

ASF>Поделитесь опытом: как интерпретировать результаты? Скажем, нормальна ли ситуация, и какие в ней меры применять, если число, в полтора раза меньше запланированного? А если вдвое больше?
Метрика нужна только для сравнения с планом. Процент закрытых задач (график количества от времени с нарастающим итогом) при сравнении с плановым значением этого графика позволяет определять отставание от плана. Отклонение в размере Loc против плана означает недооценку/переоценку сложности, т.е. ошибку планирования. Если будет тенденция к превышению loc по всем задачам, то вам станет понятно, что план нереалистичен, и его надо корректировать. Далее. Колебания продуктивности по каждой команда должны быть в районе 3 сигм от среднего. В противном случае разбирайтесь почему. Низкая продуктивность может например означать только то, что человек привык писать компактный качественный код. Кроме варианта, что люди пинают балду (в этом полагайтесь на мнение тим-лида). Слишком высокая продуктивность — хуже, она может означать, что код низкого качества.

ASF>Понятно, что следует разобраться, с чем связано любое расхождение. Но насколько быстро этот процесс выявляет истинную причину той или иной проблемы?
Не любое. Реагировать на колебания метрик в районе 3-х сигм от средних строго не рекомендуется. Метрика нужна только для сравнения с планом — как грубая агрегатная величина. Найти причину проблемы она не поможет, это уже от вас зависит. Насколько быстро? С частотой статус-митингов , т.е. с недельной задержкой.

ASF>Как предотвратить "работу на метрику", когда человек сознательно пишет побольше LOC, чтобы "обмануть" метрику или совпасть с ней?

Есть только один вариант. Сотрудники должны быть уверены, что метрики используются только для планирования, и ни при каких обстоятельствах не будут использованы для оценки их работы. И это должно быть так на самом деле. В этой связи, вы не должны видеть персональных метрик — только средние значения по командам. От греха подальше. Вам это все равно не нужно — метрики продуктивности loc/hr характеризуют только персональный стиль разработчика, а не его профессионализм. То же относится к объему в loc, который колеблется вдвое у разных людей на одной и той же задаче, и это совершенно нормально. Вам важно не это, а чтобы проект завершился в срок, а если он не укладывается в срок — узнать об этом как можно раньше и скорректировать план/порезать функционал. Все.

Метрика "количество дефектов", находимое тестерами — исключение в том смысле, что вам выгодно, чтобы люди сознательно на нее работали .