Вы писали:
G>На основании этих метрик и прочих сделать качественных выводов относительно работы команд нельзя. А если и сделаешь какие-либо выводы — то будет слишком поздно. Я бы рекомендовал в таких условиях применить процесс, ориентированный на качество, с целью предотвратить ситуацию, которой вы опасаетесь, и получить контроль над ситуацией. В следующем варианте: G>1) Делишь разработчиков на "опытных" и "неопытных", опытным даешь статус "старших". G>2) Бьешь их на группы по 3 человека, за каждым опытным закрепляешь пару неопытных. Каждая такая группа работает над близкими задачами. "Старший" отвечает также и за качество работы "младших".
Так и сделано.
G>3) Введи code inspections. Любой код, который идет в репозиторий, должен просматриваться опытным сотрудником, найденные недочеты должны исправляться. Изменений без такой ревизии быть не должно. Код опытного сотрудника, впрочем, тоже должен просматриваться одним из младших. Право решать, что такое недочет всегда остается за "старшим".
Сейчас так и сделано, но не для "любого" кода, а для такого, который желает проинспектировать "старший". Подумав лучше, прихожу к выводу, что это неверно, Вы правы.
G>4) То же самое касается design inspections. Тока в них всегда обязан принимать участие как минимум один дополнительный "старший".
Так и сделано. Более того, расписано по людям, кого из "старших" надо извещать об изменениях/достижениях/предполагаемых архитектурных решениях по каким областях знания.
G>5) Размер команд не должен превышать 5-6 человек. Назначь из старших 4-5 тимлидов, будешь дрючить их. Они за работу своих команд отличают головой. У каждого тимлида должен быть в команде еще один "старший".
Так и сделано.
G>6) Раз в неделю — статус митинги с тимлидами, с разбором полетов и метрик.
Раньше я думал, что раз в месяц хватает. Видимо, Вы правы.
G>Теперь о метриках. Регулярный еженедельный контроль следующих метрик в сравнении с планом. Обсуждается на статус митингах с тимлидами. G>1) Процент фактически закрытых задач против запланированного на каждую неделю. EV Plan и контроль его выполнения. G>2) Количество написанного кода в lines of code — сравнение с запланированным. G>3) График продуктивности LOC/day на закрытых задачах — сравнение с планом. G>Для каждой задачи нужно планировать размер в строках кода. Этого должно быть достаточно.
Поделитесь опытом: как интерпретировать результаты? Скажем, нормальна ли ситуация, и какие в ней меры применять, если число, в полтора раза меньше запланированного? А если вдвое больше?
Понятно, что следует разобраться, с чем связано любое расхождение. Но насколько быстро этот процесс выявляет истинную причину той или иной проблемы?
Как предотвратить "работу на метрику", когда человек сознательно пишет побольше LOC, чтобы "обмануть" метрику или совпасть с ней?
