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

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

C>>А зачем?
C>>А какую корневую задачу хочется решить таким способом?

C>>Я понимаю, если узнать производительность каждого разработчика на спринте, тогда можно прикинуть сколько идеальных дней можно на кого планировать,
C>>Но зачем это делать на каждый день?
[...]

P_Y>- найти подтверждение (или опровергнуть) своему субъективному чувству что человек работает плохо (или хорошо)
P_Y>- использовать для аргументации причин наказания человека (при лишении премии, увольнении и т.п.) Часто без таких цифр дольно трудно донести человеку мысль: "По моему субъективному ощущению ты работаешь слабо". Цифры помогают тут намного лучше чем эмоции.
P_Y>- отследить производительность к.л. процесса. Пока я в jira умею отслеживать только скорость появления тикетов и скорость закрытия (что происходит при выставлении любого resolution status). Но между двумя этими событиями есть кодирование, тестирование, технологическое тестирование. А какова средняя скорость исправления ошибок программистом? А сколько багов может проверить тестировщик?
P_Y>- определить есть ли взаимосвязь между различними событиями и производительностью (как работается после выпуска, выплаты бонуса, финала чемпионата мира по футболу, по понедельникам, по пятницам)

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


P_Y>и т.д. и т.п. Применений много, был бы инструмент и главное адекватные люди способные правильно им воспользоваться.

Это точно. инструмент есть, BiPulse (http://bipulse.ru), я выгружаю в него данные. после этого я могу смотреть на историю в ключе "кто и сколько сделал", так как там изменение статуса раздельно отслеживается.
Единственное, что минус — для интеграции с джирой нужно чтобы она снаружи была доступна.