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

E>Нет проблем.
У тебя нет, а у программистов есть.
E>Если ты катаясь на лыжах думаешь над задачей — пиши в отчет "думал о задаче во время катания на лыжах".
По сути, за эти часы ты должен заплатить. Ну если рассуждать как ты но с позиции программиста.
E>Менеджеры разные бывают.
Да. Бывают хорошие, плохие и очень плохие.
E>Не только чтобы оценивать. Но и для того чтобы управлять. А управлять можно только на основании информации.
Мне кажется ты не понимаешь что такое управление. Я не представляю где ты вычитал про информационные потоки, но скорее всего ты это не так понял или не верно применяешь.
E>И выбивать деньги будет менеджеру легче, если он четко знает какие работы выполняли его подчиненные.
Глядя на твои посты мне видится что ты хочешь навязать бюрократию лишь для одной цели — скинуть с себя ответственность перед заказчиком за просчёты в сроках на программиста.
E>Все-таки ты считаешь что лучше писать трудозатраты методом "наобум" — "на глаз"?
Это определяется на этапе планирования и цель инженеров уложится в сроки, а не объяснять что он делал 2 часа, а что три, и тем более получать разносы на митингах.

Как раз — нет. То как тебе собирать информацию очень зависит от того зачем она тебе.

Если тебе надо отчитываться перед заказчиками (например) и выставлять им счета то тебе нужно как можно больше времени залогать (реально залогать, а не обманывать заказчика). Если тебе надо контролировать людей таким образом — это другое (например человек сидел в столовой и думал над задачей, в первом случае тебе надо записать это время, в случае учета для сотрудников тебе это не надо). И т.д.

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

Вячеслав Педак

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

E>Я все понимаю...
E>Вопрос не в том зачем мне учет времени.

E>Вопрос в том, как этот учет осуществлять.

А представь что пока я пил чай я думал над это задачей... Это как будем относить?

Реально обычно это делается примерно. Есть оценка задачи, заказчик ее видит и согласен, работник ее делает в срок и заказчику выставляется счет на все это время.
Нафига мудрить? Заказчик захотел что-то, оценка его устраивала, он получил. Что еще надо?

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

Вячеслав Педак

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

E>Ну представь, ты решаешь задачу, отслеживаешь время, тут тебе позвонили по телефону по личному вопросу и ты проговорил 30 минут.
E>Затем снова начал работать, часа через 1,5 захотелось попить чай — пошел пить чай.
E>Потом пришел и еще за час задачу доделал.

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

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

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

это и случилось со мной, я устал вносить вручную правки, когда меня кто-то отвлек или когда я сам отвлекся на что-то.

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

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

V>Как раз — нет. То как тебе собирать информацию очень зависит от того зачем она тебе.

V>Если тебе надо отчитываться перед заказчиками (например) и выставлять им счета то тебе нужно как можно больше времени залогать (реально залогать, а не обманывать заказчика). Если тебе надо контролировать людей таким образом — это другое (например человек сидел в столовой и думал над задачей, в первом случае тебе надо записать это время, в случае учета для сотрудников тебе это не надо). И т.д.

V>Поэтому тебе и говорят, пойми зачем тебе это для начала, а потом уже можно будет понять как это собирать, в какой форме и надо ли оно вообще.
V>А ты на это начинаешь писать кучу причин зачем тебе это может быть надо и все они разные... В общем, чтобы задать вопрос надо уже знать половину ответа на него...

V>Вячеслав Педак

Основная цель: подсчет фактических трудозатрат для выставления заказчику.

Добрый день.

E>И вопросы такие:
E>1) как вообще подобные проблемы решаются у вас?
E>2) есть какие-нибудь системы, которые позволяют это делать? Желательно, чтобы они как-то были связаны с трекером

Сергей, я прочитал Вашу переписку.
Для контроля за действиями сотрудника есть утилиты типа Time Doctor, Rescue Time, Manic Time, но я КРАЙНЕ не рекомендую их использовать.
Это будет создавать палочноу мотивацию людям и может приводить к падению производительности.
По часам вы получите красивые 8 часов в день в отчете, но насколько они будут эффективными, это будет большой вопрос.
Так же опытные сотрудники могут уйти в компании где больше уважают личное пространство человека.
Как вариант большинство систем управления задачами позволяет настроить автоматический учет времени между моментом когда задача была открыта и когда закрыта.
Вы можете получать информацию оттуда.
Но лучший вариант, если Ваши сотрудники сами осознают важность предоставления информации и будут это делать.

Посмотрите на досуге сайты:
http://it-boost.com/
http://stratoplan.ru/

Возможно они будут Вам полезны.

С уважением,
Вячеслав

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

E>>Если ты катаясь на лыжах думаешь над задачей — пиши в отчет "думал о задаче во время катания на лыжах".
K>По сути, за эти часы ты должен заплатить. Ну если рассуждать как ты но с позиции программиста.
Конечно. Все это будет оплачено.
Только программист сначала должен отчитаться за эти часы, причем точно а не наобум.

E>>Не только чтобы оценивать. Но и для того чтобы управлять. А управлять можно только на основании информации.
K>Мне кажется ты не понимаешь что такое управление. Я не представляю где ты вычитал про информационные потоки, но скорее всего ты это не так понял или не верно применяешь.
Предлагаю про понятие управления обсудить в другой ветке.

E>>И выбивать деньги будет менеджеру легче, если он четко знает какие работы выполняли его подчиненные.
K>Глядя на твои посты мне видится что ты хочешь навязать бюрократию лишь для одной цели — скинуть с себя ответственность перед заказчиком за просчёты в сроках на программиста.
Выбивать деньги будет легче, если менеджер точно уверен, что выставленные трудозатраты соответствуют реальным трудозатратам.

E>>Все-таки ты считаешь что лучше писать трудозатраты методом "наобум" — "на глаз"?
K>Это определяется на этапе планирования и цель инженеров уложится в сроки, а не объяснять что он делал 2 часа, а что три, и тем более получать разносы на митингах.

Я же писал, что по этому направлению у нас другой принцип работы.
Нету никакого планирования и сроков.

Кратко повторю.
Есть несколько договоров поддержки, по которым нам заказчик оплачивает за фактически затраченное время за решение вопросов, которые по времени занимают менее 8 часов.
Фактические трудозатраты по всем этим решенным вопросам суммируются и выставляются заказчику в конце месяца с приложением списка решенных задач.
Инженер поддержки должен отчитаться по своим трудозатратам.
Если он будет писать затраты приблизительно — может пострадать как он сам (если пишет меньше чем работал), так и заказчик (если инженер пишет больше).
Вот для этого и нужен удобный инструмент.

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

J>в любой ситуации главное — задать правильный вопрос. всей темой тебе пытаемся показать, что вопрос у тебя неверный.
J>универсального рецепта не существует, ни одна из софтин трекающих активность не решает задачу так как надо конкретному человеку.
ну хоть одну из софтин назовите наконец!
выше называли, но она на веб, лучше десктопную.

J>это и случилось со мной, я устал вносить вручную правки, когда меня кто-то отвлек или когда я сам отвлекся на что-то.
у нас нет другого выхода, нам придется искать такую программу,
чтобы она была максимально удобной

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

Спасибо. Один из немногих ответов по делу.

S>Мы использовали 2 разные системы.
Эти две системы как-то связаны друг с другом?
Например, если потом приходится сопровождать и дорабатывать в Итилиуме ту задачу, которая изначально разрабатывалась в Jira?
Есть ли связь между этими задачами, которые по сути связаны?

S>2. Для сопровождения — Итилиум
А как программа точно называется?

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

E>Кратко повторю.
E>Есть несколько договоров поддержки, по которым нам заказчик оплачивает за фактически затраченное время за решение вопросов, которые по времени занимают менее 8 часов.
E>Фактические трудозатраты по всем этим решенным вопросам суммируются и выставляются заказчику в конце месяца с приложением списка решенных задач.
E>Инженер поддержки должен отчитаться по своим трудозатратам.
E>Если он будет писать затраты приблизительно — может пострадать как он сам (если пишет меньше чем работал), так и заказчик (если инженер пишет больше).
E>Вот для этого и нужен удобный инструмент.

А может имеет смысл брать деньги не за время, а за задачи? Если идете с опережением графика, то
чтобы не простаивать просите у stakeholder'а еще задач.

Здравствуйте, Вячеслав Бенедичук, Вы писали:

ВБ>Добрый день.

ВБ>Сергей, я прочитал Вашу переписку.
ВБ>Для контроля за действиями сотрудника есть утилиты типа Time Doctor, Rescue Time, Manic Time, но я КРАЙНЕ не рекомендую их использовать.
ВБ>Это будет создавать палочноу мотивацию людям и может приводить к падению производительности.
ВБ>По часам вы получите красивые 8 часов в день в отчете, но насколько они будут эффективными, это будет большой вопрос.
ВБ>Так же опытные сотрудники могут уйти в компании где больше уважают личное пространство человека.
ВБ>Как вариант большинство систем управления задачами позволяет настроить автоматический учет времени между моментом когда задача была открыта и когда закрыта.
ВБ>Вы можете получать информацию оттуда.
ВБ>Но лучший вариант, если Ваши сотрудники сами осознают важность предоставления информации и будут это делать.

ВБ>Посмотрите на досуге сайты:
ВБ>http://it-boost.com/
ВБ>http://stratoplan.ru/

ВБ>Возможно они будут Вам полезны.

ВБ>С уважением,
ВБ>Вячеслав

Спасибо, Вячеслав.
С этими сайтами знаком, не очень конечно глубоко.

ВБ>Это будет создавать палочноу мотивацию людям и может приводить к падению производительности.
ВБ>По часам вы получите красивые 8 часов в день в отчете, но насколько они будут эффективными, это будет большой вопрос.
ВБ>Так же опытные сотрудники могут уйти в компании где больше уважают личное пространство человека.

Мы ни в коей мере не хотим ущемить личное пространство человека.
И нам не нужны 8 часов в отчете. Если человек напишет даже 2-3-4 часа, к нему не будет никаких претензий.
Главная цель, для которой это все предпринимается, — сбор информации о том, сколько реально занимает выполнение конкретной задачи.
Мы понимаем, что это дополнительное обременение для человека, поэтому и стараемся сделать это максимально простым.

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

S>А может имеет смысл брать деньги не за время, а за задачи? Если идете с опережением графика, то
S>чтобы не простаивать просите у stakeholder'а еще задач.

Тогда нужно предварительно знать какая задача сколько стоит.
То есть задачам нужно назначить цену. И эта цена естественно зависит от трудоемкости задачи.
То есть чтобы в момент поступления задачи знать сколько она стоит надо по подобным задачам накопить статистику: среднее время ее решения.
Но если нет точного учета — тогда мы не имеем правдивой статистики.
Так что все равно считать время нужно.

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

E>Но если нет точного учета — тогда мы не имеем правдивой статистики.
E>Так что все равно считать время нужно.

Считайте раз нужно — Учёт времени (Time tracking).

fixed исправили мегафичу, #138 @3h30

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

Здравствуйте, es3000, Вы писали:
E>А потом он суммирует все трудозатраты и общие трудозатраты записывает в трекер для задачи.
Почитал ветку, и у вас просто какой-то ахтунг-менджмент или пособие о том, как разогнать хороших программистов и оставить только самых упоротых. Мне как программисту, не нужны никакие учеты врмени и прочая ботва, мне нужны интересные задачи и команда — на все остальное мне наплевать. Кому и сколько вы там платите и как — мне будет неудобно работать я уйду, потому что я свои умения и цену знаю. Вместо того, чтобы думать над задачей я буду думать как и сколько я времени потратил на поесть попить и покакать. Я за оценку и трекинг, но когда этот процесс не напрягает и подход адекватен. Я работал в компании где трекали поминутно чистое время на задачу — ни сколько не напрягало. Потому что была отличная команда, хороший код и удачный менджмент и отличные инструменты: кнопку нажал — запустил таймер, кнопку отжал — остановил таймер. В оценку +/- 20% попадал почти всегда. Были случаи когда естимейты вылетали и там менджмент рзбирался в проблеме, а почему? В результате то требования менялись и не фиксировались, то еще какая-то хрень, которая не связана с разработчиком и т.д. В общем это был сигнал — не более. Любой трекинг это попугаи для того чтобы хоть как-то оценить как идет разработка по времени: на каком этапе сколько времени потратили на сколько промахнулсь.

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

Вы пытаетесь проблемы бОльшего масштаба решить какой-то административной бредятеной. Чем не устраивает стандартный воркфлоу. Запрос -> задача + подзадачи?
Саппорт странный, я девелопер и я еще и на звонки должен отвечать: тут уж надо определиться либо я отвечаю, либо я пишу код и не отвлекаюсь. Подход менджмента к людям как к роботам-рабам. Людей надо любить и иногда только журить.

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

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

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

V>Считайте раз нужно — Учёт времени (Time tracking).

Наслышан про Redmine но сам не пользовался.
А есть что-нибудь десктопное?

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

Что-то ты смешал все в кучу.
Вроде говоришь что сам вел такой учет и все было прекрасно.
А потом говоришь что это плохо...

_>Я работал в компании где трекали поминутно чистое время на задачу — ни сколько не напрягало.
_>Потому что была отличная команда, хороший код и удачный менджмент и отличные инструменты: кнопку нажал — запустил таймер, кнопку отжал — остановил таймер.
И мы так хотим сделать. Чтобы было удобно и никого не напрягало.
Какой у вас был инструмент?

_>Вы пытаетесь проблемы бОльшего масштаба решить какой-то административной бредятеной.
Значит у вас такой учет — это была не бредятина, а у нас такой учет почему-то сразу бредятина.
Интересные рассуждения, где логика?

_>Саппорт странный, я девелопер и я еще и на звонки должен отвечать
Я где-то говорил, что девелопер у нас отвечает на звонки?

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

E>Наслышан про Redmine но сам не пользовался.
E>А есть что-нибудь десктопное?

Redmine (альтернатива его же форк ChiliProject). Бесплатных аналогов ему не встречал, все они в лучшем случае трекеры задач, но уж никак не системы управления проектом. К тому же он хоть и вебобвский, но всё же интерактивный. Где-то 4 года уже арендую виртуальные сервера, перешёл с шаред хостинга. И могу сказать, что десктопное решение, даже если бы было достойное, в разы хуже. Так же никто же не запрещает ставить веб на локальную машину. Но с точки зрения разработчика это представляется крайне неэффективным.

Всё что нужно программисту лежит в репозитории, а по большей части редактируется в каком-нибудь блокноте. Причём это можно делать хоть из самой навороченной IDE, хоть из консоли (vim/nano). Схемы мне нравится делать в той же Dia, и помещаю их туда же в репозиторий. И вот в чём дилемма, система управления проектом это не работа разработчика, тестировщика и прочих. То есть это действие по сути никак не оплачивается, оплачивается только то, что учтено этим действием.

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

Так же на забываем, что у коммита есть время его создания, можно узнать временную разницу между коммитами, и плюс введённая самим пользователем информация о времени, которая уже никуда из репозитория не денется, плюс автоматически обновится в системе управления проектом. Кстати, fixes это команда для автоматической смены статуса задачи, а не часть названия коммита.

Если программисту сказать, что теперь мы пишем коммиты так:

fixes исправили мегафичу, #138 @3h30

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

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

Redmine (aka ChiliProject) лучшие.
Если есть JIRA, надо найти как в ней делается тоже самое (если это возможно) и опять же не думать, а прыгать.
1. Покупаем VPS/VDS 200-400 рублей в месяц.
2. Устанавливаем и настраиваем всё что нужно.
3. Пытаемся работать.

Веб ещё хорош тем, что там же установлен репозиторий, в моём случае гитолайт, хотя можно настроить много всего. Закоммитился на работе, пришёл домой, получил данные. Изменил, закоммитился, пришёл на работу, и всё уже есть. А если людей много, тогда тем более. Даже если сервер умрёт, можно делать постоянные автобекапы, но самое главное не умрёт гит, то есть результат труда за который заплачены деньги, так как он децентрализованный.

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

Может я и разделяю опасения других участников форума, что при учёте времени всё может быть не так шоколадно, как это представляется менеджеру, но не согласен с тем, что не нужно даже пытаться внедрить, если хочется. Надо попробовать, основная работа ляжет на админа. Программисту надо запомнить только.

refs свяазно с мегафичей, #138 @0h30
fixes исправили мегафичу, #138 @2h20
closes завершили мегафичу, #138 @3h35

настраиваемые значения хранилища в админке (можно заменить на своё)

refs,references,IssueID
fixes,closes

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

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

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


_>>Я работал в компании где трекали поминутно чистое время на задачу — ни сколько не напрягало.
_>>Потому что была отличная команда, хороший код и удачный менджмент и отличные инструменты: кнопку нажал — запустил таймер, кнопку отжал — остановил таймер.
E>И мы так хотим сделать. Чтобы было удобно и никого не напрягало.
E>Какой у вас был инструмент?
Сами писали.

_>>Вы пытаетесь проблемы бОльшего масштаба решить какой-то административной бредятеной.
E>Значит у вас такой учет — это была не бредятина, а у нас такой учет почему-то сразу бредятина.
E>Интересные рассуждения, где логика?
Тут есть одно, такая система работает только там, где все остальное хорошо. И он не является определяющей, т.е. для менеджмента эта система подобие лакмусовой бумажки. Если девелопер попадает в естимейты и команда с эстимейтами согласна — все хорошо.
Но такую систему использовать как основную — вообще не вариант. Есть альтернативный подход, когда в день должно быть затрекано 5 часов например. и девелопер распределяет свое время между задачами, которыи он занимался. И в первом и втором случае это попугаи.


_>>Саппорт странный, я девелопер и я еще и на звонки должен отвечать
E>Я где-то говорил, что девелопер у нас отвечает на звонки?
Значит я что-то не так понял.

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

E>А исполнитель, выполняя эту задачу, где-то у себя отмечает:
E>1) написал процедуру "ххх1" — 1час
E>2) написал процедуру "хххх2" — 1 час

нормальный процесс работы над большим проектом — это "написал одну строчку в файле А, две строчки в файле Б и т.п."
потом у людей получаются вот такие коммиты — https://codereview.chromium.org/865543002/
где в 30 файлах изменено по 5-10 строк

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

даже если пишется новый код, "процедур xxx1" будут десятки, и на написание большинства из них уйдет 1-5 минут
при этом будет дофига операций "удалил процедуру xxx1", "перенес xxx1 в файл yyy" и т.п.

разумеется все адекватные программисты от вас убегут

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

A>каждое изменение занимает несколько минут, и если их где-то описывать, на это уйдет гораздо больше времени чем на сами изменения.
A>даже если пишется новый код, "процедур xxx1" будут десятки, и на написание большинства из них уйдет 1-5 минут
A>при этом будет дофига операций "удалил процедуру xxx1", "перенес xxx1 в файл yyy" и т.п.
A>разумеется все адекватные программисты от вас убегут

Если разработчик делает коммит через каждые 5 минут, то он прежде всего должен убежать сам от себя, так как уже ведёт сверхдетальный анализ работы. Собственно говоря от того будет он писать время или не будет, уже ничего не изменится. Вот если бы задача автора топика была не вести учёт времени, а заставить делать коммиты каждые 1-5 минут, тогда да. Но проблема мне почему-то видится в мнении, что на разработчика нужно учиться, а вот менеджером может стать любая девочка или продавец картошки. Недавно мне здесь рассказывали, что программисты никакие не учёные и Computer Science существует только за рубежом, а у нас они вроде рабочих у станка, исправно пилят детали.

А потом продавец картошки или коммуникативная девочка становятся менеджерами проектов, в какой-нибудь жирной фирме, которая может себе позволить терять разработчиков пачками, но не может позволить нанять менеджера с множеством успешно реализованных проектов. Это так же как если нанимаешь специалиста, но обращаешься не к специалисту по поиску этого вида персонала, а в фирму в которой сидит та же девочка, или к Васе Пупкину, потому что считаешь его хорошим разработчиком. А я тут в соседней теме узнал, что говнокод это оказывается единственная форма существования кода. Для Васи может быть весь код говно и все другие программисты говнокодеры по определению. А девочка может не возбудилась от мужика в свитере и обиделась, или наоборот, в свитере — не мужик, то есть ненастоящий программист. Вот имеем то, что имеем.

Чисто для примера:

cd ~/work
~/work$ git clone https://github.com/bulletphysics/bullet3
~/work$ cd ./bullet3

Cloning into 'bullet3'...
remote: Counting objects: 50853, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 50853 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (50853/50853), 70.04 MiB | 486.00 KiB/s, done.
Resolving deltas: 100% (38425/38425), done.
Checking connectivity... готово.
Checking out files: 100% (1983/1983), done.

~/work/bullet3$ gitk

Представление => Новое представление
author: erwin.coumans@gmail.com
since: 2014-08-1
until: 2014-09-1

И всё, смотрим в удобном графическом виде, что делалось и когда.

Или чтобы было понятнее команды из консоли.

git log --pretty=format:"%h %ad | %s%d [%an]" --date=short --author=erwin.coumans@gmail.com --since="2014-08-1" --before="2014-09-1"

3b7a700 2014-08-31 | Merge pull request #230 from erwincoumans/master [erwincoumans]
57b3886 2014-08-31 | Merge pull request #229 from erwincoumans/master [erwincoumans]
6760cee 2014-08-28 | Merge pull request #224 from erwincoumans/master [erwincoumans]
8595928 2014-08-28 | update appveyor badge [Erwin Coumans]
1451232 2014-08-28 | update badges for README.md [Erwin Coumans]
81bafac 2014-08-28 | rename to see if travis message works with .md extension? [Erwin Coumans]
613beab 2014-08-28 | Update readme.txt [erwincoumans]
09e758b 2014-08-28 | Update appveyor.yml [erwincoumans]
4004ab4 2014-08-28 | Update appveyor.yml [erwincoumans]
7c4a5fc 2014-08-28 | Update appveyor.yml [erwincoumans]
8f27aaa 2014-08-28 | Update appveyor.yml [erwincoumans]
d0d6de1 2014-08-28 | Update appveyor.yml [erwincoumans]
aa8c1e9 2014-08-28 | Create appveyor.yml [erwincoumans]
a51382e 2014-08-28 | Merge pull request #223 from erwincoumans/master [erwincoumans]
e40606e 2014-08-26 | Merge pull request #222 from erwincoumans/master [erwincoumans]
3c558ec 2014-08-26 | explicitly deserialize btCapsuleShape date (margin, scaling, halfextents), because the API modifies them [
a0778a1 2014-08-26 | CMakeLists.txt: OSX check is below 10.9 (not below 10.10), and add new files [Erwin Coumans]
2b35911 2014-08-26 | X11OpenGLWindow: create stencil buffer for shadows in OpenGL2 mode (OpenGL3 uses shadow maps) Add 'createC
1e956c8 2014-08-25 | Merge pull request #220 from erwincoumans/master [erwincoumans]
6cbf899 2014-08-25 | move the clearForceAndTorque to after the stepVelocities, see also https://github.com/bulletphysics/bullet
8e64ee5 2014-08-22 | fix a few warnings, and matching class/struct in forward declaration [Erwin Coumans]
2c19a27 2014-08-22 | add missing ConstraintPhysicsSetup.* files [Erwin Coumans]
954d488 2014-08-22 | cmake+premake disable OpenGL 3 demos on Mac OSX versions below 10.9 See also http://www.bulletphysics.org/
ade897c 2014-08-22 | Merge pull request #219 from erwincoumans/master [erwincoumans]
bc96d5e 2014-08-22 | Update ImportURDFSetup.cpp [erwincoumans]
edbc187 2014-08-22 | Merge pull request #218 from erwincoumans/master [erwincoumans]
e1e54f7 2014-08-21 | Merge pull request #217 from erwincoumans/master [erwincoumans]
60ab931 2014-08-21 | Merge pull request #216 from erwincoumans/master [erwincoumans]
4118495 2014-08-21 | Merge pull request #215 from erwincoumans/master [erwincoumans]
590504b 2014-08-21 | Merge pull request #201 from bgossage/fix_pointer_cast [erwincoumans]
ed637a6 2014-08-20 | fix mac build [Erwin Coumans]
cb55f7d 2014-08-20 | Merge pull request #214 from erwincoumans/master [erwincoumans]
7b28e86 2014-08-20 | add improved btGeneric6DofSpring2Constraint, thanks to Puhr Gabor and Tamas Umenhoffer! improved the new d
d2509ae 2014-08-19 | Merge pull request #212 from erwincoumans/master [erwincoumans]
cd22ccd 2014-08-19 | Merge pull request #187 from filipwasil/subproject_build_fix [erwincoumans]
34baab5 2014-08-19 | Merge pull request #196 from jackoalan/parallel_linear_bvh_cl_fix [erwincoumans]
2442977 2014-08-12 | Merge pull request #209 from erwincoumans/master [erwincoumans]
4027ed0 2014-08-03 | Merge remote-tracking branch 'bulletphysics/master' [Erwin Coumans]
5ed49cc 2014-08-03 | fix missing implementation [Erwin Coumans]
f85e251 2014-08-03 | add missing files to CMakeLists [Erwin Coumans]
ae98ffe 2014-08-03 | add Obj and STL import demo, work on URDF import [Erwin Coumans]
ba5a8a4 2014-08-03 | Merge remote-tracking branch 'bulletphysics/master' [Erwin Coumans]

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

https://ru.wikipedia.org/wiki/Метрика_программного_обеспечения

Потенциальные недостатки подхода, на которые нацелена критика:

Неэтичность: Утверждается, что неэтично судить о производительности программиста по метрикам, введенным для оценки эффективности программного кода. Такие известные метрики, как количество строк кода и цикломатическая сложность, часто дают поверхностное представление об "удачности" выбора того или иного подхода при решении поставленных задач, однако, нередко они рассматриваются, как инструмент оценки качества работы разработчика. Такой подход достаточно часто приводит к обратному эффекту, приводя к появлению в коде более длинных конструкций и избыточных необязательных методов.
Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества
Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
Неточность: Нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представление о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.

https://compscicenter.ru/media/slides/seintro_2012_spring/2012_05_14_seintro_2012_spring.pdf
https://www.lektorium.tv/lecture/13787