Проанализируйте репозитории SVN / GIT, чтобы определить, сколько работы фактически сделано?

Question

Один из моих клиентов использует для проекта программиста из другого штата. Он не может понять, сколько работы на самом деле делает программист, поэтому он боится, что деньги потенциально пойдут на ветер.

Что мне интересно, возможно ли использовать SVN или GIT-репозиторий, чтобы вычислить или оценить, сколько реальной работы фактически выполняется? Что-то вроде нахождения различий между двумя изменениями или заданным периодом времени и предоставления резюме / обзора проделанной работы?

Очевидно, что вы можете просто добавить или удалить пробел в некотором коде, и SVN увидит его как изменение после фиксации, но это не означает, что какая-либо работа была фактически выполнена. Возможно, есть некоторые методы или сценарии, которые могут принять во внимание все эти вещи и, возможно, проанализировать разницу в размерах файлов и т. Д. И определить, какая работа была выполнена.

И, конечно, вы можете вручную проверять ревизии и запускать на них различия, но было бы полезно получить более подробную информацию обо всем.

В любом случае, есть что-нибудь подобное?

Answer 1

Единственное, что анализирует хранилище, скажет вам, сколько кода было изменено.Вам нужен другой программист, чтобы посмотреть на него, чтобы действительно сказать вам, сколько работы ушло на эти изменения.Небольшой коммит, возможно, потребовал огромного количества размышлений, в то время как большой коммит было действительно легко сделать, поскольку он был простой частью программы.Например, Redmine может предоставить вам график, показывающий, сколько изменений внес человек и сколько кода было изменено.

Answer 2

Нет никакого программного обеспечения, чтобы делать то, что вы просите. Вы можете найти вещи, чтобы проанализировать размер коммитов и частоту таких коммитов, но нет программного обеспечения, которое могло бы взять эти цифры и превратить их в объем работы, проделанной разработчиком.

Вместо этого клиент должен настаивать на быстром процессе разработки, при котором программист регулярно демонстрирует прогресс или обсуждает с клиентом любые проблемы, которые у него возникают по поводу разработки и бизнес-логики.

Answer 3

Это похоже на типичный случай, когда люди хотят использовать инструменты, чтобы избежать личных отношений.

Я твердо верю, что ничего хорошего из этого не выйдет. Люди будут вести себя так, как их измеряют. Когда используются простые метрики в виде добавленных строк кода, вы получите много кода. Однако вы будете отговаривать от усилий по рефакторингу, которые обычно уменьшают код!

Если подсчитать измененные строки, переформатирование базы кода приведет к тому, что в работах по мониторингу возникнет гаечный ключ, и будет отмечена остальная часть команды разработчиков.

Если линии изменились независимо от пробелов, вы только что установили первый шаг на скользком склоне, который закончится тем, что на мониторинг производительности будет затрачено больше усилий, чем на производство продуктов.

То, что я бы порекомендовал, - это мониторинг предоставляемых функций и QA-d, обзоры кода, еженедельные индивидуальные занятия, измерение присутствия и входных данных во время собраний, а также запрашивание информации от коллег.

При этом, я думаю, что Sonar - довольно хороший инструмент для мониторинга прогресса и показателей качества. Но это будет трудно использовать для нацеливания на людей.

Answer 4

Вы можете посмотреть на StatSVN .

В сочетании с некоторой случайной раздачей проверок и обвинений svn, и вы можете почувствовать.