Хочу собирать статистику по программистам, кто сколько тикетов перевел из состояния "In Progress" в следующее (у нас Coding Complite но это не принципиально) за вчерашний день.
Фильтр для задач:
status changed AFTER -1d FROM "In Progress"
Остаются вопросы:
1) как подсчитать кто сколько исправил? По идее можно для каждого программера написать фильтр с ипользованием
status changed AFTER -1d FROM "In Progress" BY "Vasia Pupkin"
но при большом количестве людей это не подходящий вариант.
2) и конечно хочется не только за последний день, но вообще с разбивкой по дням. Т.е. сформировать таблицу Дата/Кто поменял статус/Количество.
Здравствуйте, P_YegreS_P, Вы писали:
P_Y>Добрый день.
P_Y>Хочу собирать статистику по программистам, кто сколько тикетов перевел из состояния "In Progress" в следующее (у нас Coding Complite но это не принципиально) за вчерашний день.
P_Y>Фильтр для задач: P_Y>
P_Y>status changed AFTER -1d FROM "In Progress"
P_Y>
P_Y>Остаются вопросы: P_Y>1) как подсчитать кто сколько исправил? По идее можно для каждого программера написать фильтр с ипользованием P_Y>
P_Y>status changed AFTER -1d FROM "In Progress" BY "Vasia Pupkin"
P_Y>
P_Y>но при большом количестве людей это не подходящий вариант.
Брать людей, например, из домена (AD) и автоматически генерировать такие запросы-скрипты.
Здравствуйте, P_YegreS_P, Вы писали:
S>>Брать людей, например, из домена (AD) и автоматически генерировать такие запросы-скрипты.
P_Y>А что значит генерировать запросы-скрипты? Может подскажете какой нибудь tutorial?
Я имел ввиду автоматически генерировать фильтры. Как интерфейс есть у джиры я не знаю, наверняка есть какой-нибудь API.
Здравствуйте, P_YegreS_P, Вы писали:
P_Y>Добрый день.
P_Y>Хочу собирать статистику по программистам, кто сколько тикетов перевел из состояния "In Progress" в следующее (у нас Coding Complite но это не принципиально) за вчерашний день.
P_Y>2) и конечно хочется не только за последний день, но вообще с разбивкой по дням. Т.е. сформировать таблицу Дата/Кто поменял статус/Количество.
А зачем?
А какую корневую задачу хочется решить таким способом?
Я понимаю, если узнать производительность каждого разработчика на спринте, тогда можно прикинуть сколько идеальных дней можно на кого планировать,
Но зачем это делать на каждый день?
Здравствуйте, Sharov, Вы писали:
S>Я имел ввиду автоматически генерировать фильтры. Как интерфейс есть у джиры я не знаю, наверняка есть какой-нибудь API.
Есть! И даже прекрасно работает.
Здравствуйте, comm, Вы писали:
C>А зачем? C>А какую корневую задачу хочется решить таким способом?
C>Я понимаю, если узнать производительность каждого разработчика на спринте, тогда можно прикинуть сколько идеальных дней можно на кого планировать, C>Но зачем это делать на каждый день?
Существуют три вида лжи: ложь, наглая ложь и статистика
Понятно, что если опираться только на описанный мной показатель, то принимать управленческие решения будет сложно.
Но если использовать его вместе с другими — субъективным ощущением, оценками коллег и т.п. то статистика может помочь.
Пару применений:
— найти подтверждение (или опровергнуть) своему субъективному чувству что человек работает плохо (или хорошо)
— использовать для аргументации причин наказания человека (при лишении премии, увольнении и т.п.) Часто без таких цифр дольно трудно донести человеку мысль: "По моему субъективному ощущению ты работаешь слабо". Цифры помогают тут намного лучше чем эмоции.
— отследить производительность к.л. процесса. Пока я в jira умею отслеживать только скорость появления тикетов и скорость закрытия (что происходит при выставлении любого resolution status). Но между двумя этими событиями есть кодирование, тестирование, технологическое тестирование. А какова средняя скорость исправления ошибок программистом? А сколько багов может проверить тестировщик?
— определить есть ли взаимосвязь между различними событиями и производительностью (как работается после выпуска, выплаты бонуса, финала чемпионата мира по футболу, по понедельникам, по пятницам)
и т.д. и т.п. Применений много, был бы инструмент и главное адекватные люди способные правильно им воспользоваться.
Здравствуйте, 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), я выгружаю в него данные. после этого я могу смотреть на историю в ключе "кто и сколько сделал", так как там изменение статуса раздельно отслеживается.
Единственное, что минус — для интеграции с джирой нужно чтобы она снаружи была доступна.
