Что это?
Суть в том, чтобы из хранилища кода SVN собрать историю работы над проектом. В эту историю могут входить количество строк кода, время комитов, активность авторов комитов и т.д.
Зачем?
Вообще я не любитель собирать такие метрики, но меня заинтересовало наблюдение Сергея Архипенкова. Я говорю о принципе цикличности при становлении команды.
Сергей заметил, что графики количества строк кода и фаз становления команды выглядят очень похоже. Дело в том, что сначала команда собирается и происходит разработка основных компонентов (формирование команды). В этот период пишется «скелет» системы, кода мало. Потом команду «штормит» и все приходит в норму. Здесь пишется основной код. И, наконец, команда выходит на максимальный уровень производительности. А вот тут уже все написано, остается только рефакторить и исправлять ошибки. Это то самое место, когда количество строчек кода уменьшается.
Для меня это пока только теория. Отсюда и появился мой практический интерес поэксперементировать на нашем проекте. Также я хотел проверить есть ли зависимость количества строк кода или других метрик от графиков, которые представлены в статье про технические долги.
Сразу надо сказать, что сбор метрик я точно не буду применять для:
- вычисления производительности отдельных программистов
- привязки премий, зарплат и т.п. к этим метрикам
Какие решения нашел?
StatSVN
Сайт – http://www.statsvn.org
Работает в два этапа:
- нужно самим выгрузить лог SVN за интересующий период времени
- запустить формирование отчета с помощью этой утилиты
Отчеты формирует довольно симпатичные, но работает очень долго. Отчет для 6000 ревизий занял где-то 1,5 часа и напрочь повесил компьютер.
SVNPlot
Сайт – http://code.google.com/p/svnplot
Работает тоже в два этапа, но по другому принципу:
- создает базу данных sqlite из хранилища SVN
- формирует отчет с помощью запросов к базе данных
Работает на порядок быстрее, чем StatSVN.
Из недостатков можно отметить, что для ее работы надо установить много разных программ: python 2.6, sqlite3, pysvn, NumPy, Matplotlib
Сразу заметил
1. Зависимость возрастания строчек кода от времени в нашем проекте оказалась линейной (интересно, где предел?).
Т.е. цикличности никакой не наблюдается. Возможно пока не наблюдается, а может этот принцип просто не для нашего проекта. Еще один вариант – потому что мы занимается рефакторингом постоянно. В любом случае простого ответа на этот вопрос не нашел.
Дополнение
Если увеличить масштаб графика, то получим довольно занятную картинку:
Зеленые стрелочки отмечают вершины графика или то место, где график практически ровный. Оказалось, что эти стрелочки отмечены на расстоянии одной итерации (одна неделя). Это и логично, потому что после каждой итерации разработчики некоторое время тратят на рефакторинг и исправление ошибок. Отсюда вывод, что цикличность все-таки есть.
2. Саня комитит по ночам!
А как же 40-часовая рабочая неделя? ;)
В остальных метриках пока никакого толку не увидел. Например, есть довольно забавные графики активности:
Он что-то значит? Может быть первый программист больше рефакторит, чем последний? Нет, конечно. Все работают в парах и комиты могут делать с разных компьютеров. Можно только примерно сказать, что код в основном изменяется, а не добавляется новый. Опять же, это что-то значит?
Буду смотреть дальше, может какие закономерности под руку попадутся :)
Ссылки
Ну вообще, мне кажется у тебя правильный график получился. Даже если выделять время на рефакторинг и заниматься чисто им, то спада графика не будет, ты же не код половины проекта убиваешь, будет маленький спадик.
ОтветитьУдалитьНу а твой график ты логично объяснил - при постоянном рефакторинге оно так и будет.
Вообще, интересно, пиши свои наблюдения на эту тему еще. Интересно посмотреть что получится. :)
Александр, привет!
ОтветитьУдалитьИнтересный график. Слушай, а у вас есть итерации? Если есть, то на графике должны быть "полки" в то время, когда идет очередной раунд тестирования, исправляются баги и код практически не растет.
Сергей Архипенков.
Да, итерации есть.
ОтветитьУдалитьПервую половину графика они были по 2 недели, а сейчас идут по одной.
Я бы не сказал, что мы натыкались на такие мощные исправления, когда код вообще перестает прибавляться. Опять же может потому, что мы пишем сначала тесты, т.е. используем TDD в чистом виде. Да, ошибки конечно вылезают, но их практически всегда было довольно легко локализовать и соответственно исправить.
Опять же у меня пока одни гипотезы, никаких экспериментов в доказательство или опровержение не имеется =)
Привет, Саша!
ОтветитьУдалитьТы не мог бы пояснить что происходит с командой/проектом в точке на графике, где кривая резко идет вниз? Если я правильно понимаю график, то он говорит о том, что, если вовремя не поменять состав команды, она уйдет в стадию стагнации. Неужели это так?
@Dmitry
ОтветитьУдалитьЗная сколько усилий надо приложить, чтобы команду сформировать, я бы не стал менять ее состав. Скорее надо поменять цели проекта, попробовать достать до новых вершин или сменить сам проект.
Я думаю это вопрос скорее к Сергею Архипенкову =) Сергей, может прокомментируете?
Еще про масштаб. Это график практически годовых изменений. Т.е. если посмотреть, то там можно увидеть периоды падений или, как минимум, остановок.
ОтветитьУдалить2Dmitry
ОтветитьУдалитьОкружение и команда изменяются по ходу проекта. Прежняя мотивация ослабевает или перестает действовать. Главная задача руководителя - «точить пилу». «Точить пилу» - это значит работать на опережение, «играть от защиты».
Постоянный мониторинг и оценка эффективности всех процессов, используемых в проекте. «Что лишнее мы делаем?» «Что можно делать проще?» «Что угрожает проекту?». Сокращение ненужных усилий вместо «стремления к новым победам».
Определение узких мест и применение корректирующих действий там, где процессы начинают буксовать или риски слишком велики.
Ну, и естественно, если мы изменяем внутренние процессы в команде, то производительность сначала падает, потому что по-старому работать нельзя, а по-новому пока не научились.
Разумеется, делать это следует, после сдачи очередного релиза программного продукта, ну и, возможно, в случае глубокого кризиса проекта.
Где-то так.
АС.
@Sergey
ОтветитьУдалитьСпасибо за комментарий.
Я увеличил масштаб графика и заметил интересную цикличность, которая завязана на итерации. График поместил под предыдущим.
@Sergey
ОтветитьУдалитьСпасибо за комментарий.
На самом деле интересное наблюдение. Получается, что в фазе максимальной эффективности команды, она производит минимальное количество нового кода, хотя, казалось бы, именно в этой фазе должен быть самый большой прирост проекта. Или же дело в том, что производительность команды все-таки не прямо пропорциональна количеству строк кода.
@Dmitry
ОтветитьУдалитьЯ думаю, что на максимальной продуктивности продукт докручивается, допиливается. Т.е. происходит качественный скачек, а не количественный.
Интересно, можно как-то качество проекта измерять? Хотя бы в попугаях =) В голову приходят метрики FxCop и NDepend, но они не всегда являются 100% индикатором качества. Может есть какие-то идеи на этот счет?
Хочу уточнить.
ОтветитьУдалитьЯ говорил о _качественном_ подобии графиков, а не о прямой корреляции. Итерация может длится одну неделю, а цикл у команды может быть полгода.
АС.
@Sergey
ОтветитьУдалитьЯсно, просто у меня фактически видны только подобные циклы по итерациям. В общем, время покажет, сейчас гадать смысла большого не вижу.
@Александр
ОтветитьУдалитьПриведенная диаграмма и правда не самый показательный пример для подтверждения наблюдения Сергея. Может быть, дело в методологии?
@Dmitry
ОтветитьУдалитьКак я уже говорил, гадать не буду =)
Svnplot под линуксом работает только в иксах, или не пробовали?
ОтветитьУдалить@LoveSan
ОтветитьУдалитьНет, не пробовали.
Спасибо, интересно :) Надо будет с нашей CVS такое же сделать, посмотреть :)
ОтветитьУдалить