Нет. У вас своя точка зрения, у меня своя. Мы пытались друг друга переубедить, но в итоге каждый остался при своём, потому что мой опыт говорит мне одно, а вам - другое.
Я вас ни в чём не обвинял: "%{username}, перелогиньтесь", - довольно старая шутка.
Откуда вы взяли информацию про загрузку ручной работой программистов? В той статье ничего подобного нет.
Я, честно, устал вам повторять: программисты вручную делают дашборды для каждого проекта, вместо того, чтобы либо сами менеджеры делали эти дашборды, т.к. они им нужны, а не тимлидам, либо все дашборды были автоматизированы. Но вы упорно отказываетесь видеть в этом ручной труд. Такое впечатление, что вам что-то не позволяет это сделать.
Я так понимаю, потому что основная цель была отслеживать качество по отдельным проектам.
Цель была - сделать инструмент для топ-менеджмента, позволяющий сравнить команды между собой. Кто перформит, а кто - нет. Отслеживание качества у них и так было. Об этом вы и сами писали, но уже, видимо, забыли.
Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым issue можно и так прекрасно собрать.
А если нужна статистика по репозиториям, то в коммитах есть email автора. Берём его, находим в Джире его аккаунт - вот и понятно к какой команде он относится.
Сделать скрипт и запускать его ночью, чтобы он пробегал по всем репозиториям в компании, делал статистику по Джире и делал отчёты для менеджмента, как раз к их утренней чашке кофе, в разрезе по каждой команде разработки отдельно со сводным по всем командам.
Один раз назначить сквозной тэг команде, который она будет везде ставить в коммитах и тасках, а потом автоматически брать все проекты компании, фильтровать по тэгу и выводить в 1 дашборд на команду? Не, это слишком просто, пусть тимлиды вручную с дашбордами трахаются.
В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.
Дашборд создаётся вручную, к нему указываются фильтры для Jira, ключи проектов, типы задач и прочее. Всем этим фильтрам надо следовать и добавлять новые в дашборд, если они появились.
Я про это ведение дашборда.
У них уже 625 дашбордов и каждый месяц количество дашбордов увеличивается на 30 (10 качества+20 базовых).
При этом в каждой команде свои процессы и подходы к метрикам.
Т.е. у каждой команды были свои метрики.
Практика разбора дефектов была у многих команд
У многих, но не у всех. У оставшихся не было практики разбора дефектов. Но так как метрики были в каждой команде (см. предыдущую цитату), значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.
Что произойдёт с метриками команд, у которых были другие метрики? Риторический.
Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным.
Это по словам менеджера Ирины =) У нас нету реакции программистов на эти нововведения. Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
В самом начале текста у Ирины есть целеполагание: топ-менеджмент захотел инструмент, чтобы "соотнести команды между собой", но в статье нет ответа зачем это понадобилось менеджменту =)
И если подвести итоги той статьи, то:
Дашборд для топ-менеджмента так и не был создан. Т.е. задача не была выполнена.
Программисты Тинькоф теперь должны не только писать код, доументировать, Jira и т.п., но и вести свой дашборд качества. Т.е. топ-менеджмент создал дополнительную нагрузку на программистов, хотя отчёты нужны менеджменту, и, как мне кажется, менеджмент и должен заниматься этими отчётами.
Я прочитал статью "Сказ про то, как мы метрики качества внедряли", где топ-менеджмент поставил задачу руководителю по обеспечению качества, Ирине, выработать единую метрику, чтобы сравнить команды разработки между собой.
Ирина выработала набор метрик, который теперь является единым всей компании - теперь это метрики по дефектам.
Если раньше какая-то команда оценивалась по Scrum метрикам, то теперь Scrum метрики не используются для оценки эффективности команды, теперь используются новые метрики по дефектам от Ирины.
В "Сказе" сама Ирина пишет, что у команд были свои процессы и подходы к метрикам. Ирина работает в Тинькоф. Я даже не знаю, какая и от кого вам ещё информация нужна.
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".
Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
До изменений они там уже были:
в каждой команде (были) свои процессы и подходы к метрикам - из "Сказ про то, как мы метрики качества внедряли"
Далее, по тексту "Сказа", менеджер уничтожил старые метрики и сделал новые.
Я пользуюсь Gickup: https://github.com/cooperspencer/gickup
До подтирания или после?
Сколько минут?
Ваш опыт говорит, что программисты "не тратят какое-то статистически значимое время на создание этих дашбордов", так?
Нет. У вас своя точка зрения, у меня своя. Мы пытались друг друга переубедить, но в итоге каждый остался при своём, потому что мой опыт говорит мне одно, а вам - другое.
Я вас ни в чём не обвинял: "%{username}, перелогиньтесь", - довольно старая шутка.
Олег, перелогиньтесь.
Мне кажется, что сейчас ещё рано спрашивать что бы то ни было у ребят из Тинька - Ирина ещё не доделала дашборд для топ-менеджмента.
Откуда вы взяли информацию про загрузку ручной работой программистов? В той статье ничего подобного нет.Я, честно, устал вам повторять: программисты вручную делают дашборды для каждого проекта, вместо того, чтобы либо сами менеджеры делали эти дашборды, т.к. они им нужны, а не тимлидам, либо все дашборды были автоматизированы. Но вы упорно отказываетесь видеть в этом ручной труд. Такое впечатление, что вам что-то не позволяет это сделать.
Я так понимаю, потому что основная цель была отслеживать качество по отдельным проектам.Цель была - сделать инструмент для топ-менеджмента, позволяющий сравнить команды между собой. Кто перформит, а кто - нет. Отслеживание качества у них и так было. Об этом вы и сами писали, но уже, видимо, забыли.
А зачем тогда загружать ручной работой программистов? Почему dashboard per project? Почему так и не сделали сводный отчёт для топ-менеджмента?
Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым issue можно и так прекрасно собрать.
А если нужна статистика по репозиториям, то в коммитах есть email автора. Берём его, находим в Джире его аккаунт - вот и понятно к какой команде он относится.
Сделать скрипт и запускать его ночью, чтобы он пробегал по всем репозиториям в компании, делал статистику по Джире и делал отчёты для менеджмента, как раз к их утренней чашке кофе, в разрезе по каждой команде разработки отдельно со сводным по всем командам.
Один раз назначить сквозной тэг команде, который она будет везде ставить в коммитах и тасках, а потом автоматически брать все проекты компании, фильтровать по тэгу и выводить в 1 дашборд на команду? Не, это слишком просто, пусть тимлиды вручную с дашбордами трахаются.
он строится сам при открытии страницыВ итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.Дашборд создаётся вручную, к нему указываются фильтры для Jira, ключи проектов, типы задач и прочее. Всем этим фильтрам надо следовать и добавлять новые в дашборд, если они появились.
Я про это ведение дашборда.
У них уже 625 дашбордов и каждый месяц количество дашбордов увеличивается на 30 (10 качества+20 базовых).
В самом начале
При этом в каждой команде свои процессы и подходы к метрикам.Т.е. у каждой команды были свои метрики.
Практика разбора дефектов была у многих командУ многих, но не у всех. У оставшихся не было практики разбора дефектов. Но так как метрики были в каждой команде (см. предыдущую цитату), значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.Что произойдёт с метриками команд, у которых были другие метрики? Риторический.
Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным.Это по словам менеджера Ирины =) У нас нету реакции программистов на эти нововведения. Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
@nneeoo спасибо, что написали статью. Может изложение, как тут пишут, "от Олега" и эмоционально, но зато от души.
После вашей статьи я прочитал статью @irintus.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
В самом начале текста у Ирины есть целеполагание: топ-менеджмент захотел инструмент, чтобы "соотнести команды между собой", но в статье нет ответа зачем это понадобилось менеджменту =)
И если подвести итоги той статьи, то:
Дашборд для топ-менеджмента так и не был создан. Т.е. задача не была выполнена.
Программисты Тинькоф теперь должны не только писать код, доументировать, Jira и т.п., но и вести свой дашборд качества. Т.е. топ-менеджмент создал дополнительную нагрузку на программистов, хотя отчёты нужны менеджменту, и, как мне кажется, менеджмент и должен заниматься этими отчётами.
Мы с вами разные статьи прочитали?
Я прочитал статью "Сказ про то, как мы метрики качества внедряли", где топ-менеджмент поставил задачу руководителю по обеспечению качества, Ирине, выработать единую метрику, чтобы сравнить команды разработки между собой.
Ирина выработала набор метрик, который теперь является единым всей компании - теперь это метрики по дефектам.
Если раньше какая-то команда оценивалась по Scrum метрикам, то теперь Scrum метрики не используются для оценки эффективности команды, теперь используются новые метрики по дефектам от Ирины.
В "Сказе" сама Ирина пишет, что у команд были свои процессы и подходы к метрикам. Ирина работает в Тинькоф. Я даже не знаю, какая и от кого вам ещё информация нужна.
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
До изменений они там уже были:
в каждой команде (были) свои процессы и подходы к метрикам - из "Сказ про то, как мы метрики качества внедряли"Далее, по тексту "Сказа", менеджер уничтожил старые метрики и сделал новые.
Ох уж эти адепты "русского" языка. "Сопрограмма" и "фьючерс" давно стали русскими словами?
И "инстанцирование" как вдруг стало "конкретизированием"?
Всё верно написано.
Вся инвентаризация - посмотрите в сторону Nornir, потом подключите Scrapli: https://carlmontanari.github.io/scrapli/
Через плагин https://github.com/scrapli/nornir_scrapli
К Scrapli можно подключить TextFSM, вбить в шаблон команды коммутатора и радоваться нормальному выводу от команд.