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