Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым issue можно и так прекрасно собрать.
А если нужна статистика по репозиториям, то в коммитах есть email автора. Берём его, находим в Джире его аккаунт - вот и понятно к какой команде он относится.
Сделать скрипт и запускать его ночью, чтобы он пробегал по всем репозиториям в компании, делал статистику по Джире и делал отчёты для менеджмента, как раз к их утренней чашке кофе, в разрезе по каждой команде разработки отдельно со сводным по всем командам.
Один раз назначить сквозной тэг команде, который она будет везде ставить в коммитах и тасках, а потом автоматически брать все проекты компании, фильтровать по тэгу и выводить в 1 дашборд на команду? Не, это слишком просто, пусть тимлиды вручную с дашбордами трахаются.
В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.
Дашборд создаётся вручную, к нему указываются фильтры для Jira, ключи проектов, типы задач и прочее. Всем этим фильтрам надо следовать и добавлять новые в дашборд, если они появились.
Я про это ведение дашборда.
У них уже 625 дашбордов и каждый месяц количество дашбордов увеличивается на 30 (10 качества+20 базовых).
При этом в каждой команде свои процессы и подходы к метрикам.
Т.е. у каждой команды были свои метрики.
Практика разбора дефектов была у многих команд
У многих, но не у всех. У оставшихся не было практики разбора дефектов. Но так как метрики были в каждой команде (см. предыдущую цитату), значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.
Что произойдёт с метриками команд, у которых были другие метрики? Риторический.
Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным.
Это по словам менеджера Ирины =) У нас нету реакции программистов на эти нововведения. Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
В самом начале текста у Ирины есть целеполагание: топ-менеджмент захотел инструмент, чтобы "соотнести команды между собой", но в статье нет ответа зачем это понадобилось менеджменту =)
И если подвести итоги той статьи, то:
Дашборд для топ-менеджмента так и не был создан. Т.е. задача не была выполнена.
Программисты Тинькоф теперь должны не только писать код, доументировать, Jira и т.п., но и вести свой дашборд качества. Т.е. топ-менеджмент создал дополнительную нагрузку на программистов, хотя отчёты нужны менеджменту, и, как мне кажется, менеджмент и должен заниматься этими отчётами.
Я прочитал статью "Сказ про то, как мы метрики качества внедряли", где топ-менеджмент поставил задачу руководителю по обеспечению качества, Ирине, выработать единую метрику, чтобы сравнить команды разработки между собой.
Ирина выработала набор метрик, который теперь является единым всей компании - теперь это метрики по дефектам.
Если раньше какая-то команда оценивалась по Scrum метрикам, то теперь Scrum метрики не используются для оценки эффективности команды, теперь используются новые метрики по дефектам от Ирины.
В "Сказе" сама Ирина пишет, что у команд были свои процессы и подходы к метрикам. Ирина работает в Тинькоф. Я даже не знаю, какая и от кого вам ещё информация нужна.
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".
Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
До изменений они там уже были:
в каждой команде (были) свои процессы и подходы к метрикам - из "Сказ про то, как мы метрики качества внедряли"
Далее, по тексту "Сказа", менеджер уничтожил старые метрики и сделал новые.
Я видел один из выходов: Sponsorware. Вкратце, вы далаете частный проект только для споноров на Github, например, но когда количество спонсоров перерастёт некоторое значение - проект переходит в open-source.
Буква или дух - я думаю, что юристы MongoDB и Elasticsearch лучше разбираются в американских законах =)
FSF и не должен судиться - у FSF другая миссия. Это сама компания должна судиться в том случае, если её права нарушены. Лицензия GPL просто предоставляет ей такое право, не более. Юристы MongoDB посчитали, что в суде против Amazon с текущей лицензией у них мало шансов и они поменяли лицензию.
Если нужен копилефт с отягощением на некомерческое использование, то такая лицензия уже есть - называется Academic Public License, которая, например, используется компанией OMNeT++: https://omnetpp.org/intro/license
Т.к. сама лицензия в Public Domain, то вы можете применять её к своему программному обеспечению.
А как вы думаете, нужно ли решать вопрос с компенсацией разработчикам открытого ПО
Да, нужно. Раньше, до массового использования github/gitlab, это не было так очевидно, как мне кажется.
Я лично не вижу будущего у GPL v3 в том виде, в котором он сейчас есть.
Уже начались проблемы с тем, что SaaS vendor может использовать ПО GPL и при этом не следовать лицензии GPL и даже если код лицензирован по AGPL, где указано, что вы должны предоставить исходный код, если пользователи взаимодействют с ПО по сети, то это легко обходится просто вставив какой-нибудь прокси между AGPL ПО и пользователем.
И пока я вижу, что вместо поиска выхода из такого положения, FSF сейчас делает вид, что такой проблемы не существует.
Удивительно, как плохо люди понимают лицензию GPL даже в таких компаниях как Github.
Автор faker.js никому ничего не должен. Ни поддержки, ни работающей программы - ничего. Код предоставляется "как есть".
Пользователи его программы должны использовать свой форк в своём репозитории. В этом смысл GPL. А со своим репозиторием автор может делать всё, что угодно.
Для меня удивительно, что вообще существуют репозитории пакетов типа NPM.
Я вот смотрю на остальные репозитории пакетов свободного ПО - у них есть мейнтейнеры, которые фактически делают копию репозитория какой-нибудь программы и проверяют её работу на определённом дистрибутиве.
Мне кажется, если вы делаете коммерческое ПО на основе ПО со свободной лицензией, у вас должен быть свой личный репозиторий и свои мейнтейнеры. И всё ПО, что вы используете по свободным лицензиям, должно быть там.
Очевидно, что у Amazon, в случае использования такого подхода к пакетам свободного ПО, ничего бы не сломалось, и проблема была бы решена ещё на этапе обновления версии пакета в личном репозитории Amazon мейнтейнером.
GNU-BY-NC - не существует и сомневаюсь, что будет существовать когла-либо, т.к. у FSF есть определённые понятия свободного кода. Т.к. в этом случае получается правовая коллизия, когда сторонний коммитер не имеет права продать свой же код, т.е. вы отбираете у него свободу, и поэтому эта лицензия не может быть свободной.
Я 8 лет работал сисадмином в провинции
В шесть утра я вставал, бежал на электричку, ехал в Москву, работал там весь день
Ну, об этом уже писали.
В серверной все было запитано через кучу сетевых фильтров. Однажды они не выдержали пары скачков напряжения, кнопка на одном из фильтров запаялась, все заискрило.
У админа точно есть высшее образование? А такое впечатление, что нет.
Приходишь в контору, видишь безобразие по электрике — вызываешь инженера-электрика — переделываете всё как надо.
Хорошо, что обычно я задерживался и уходил с работы последним…
8 лет
Что он там 8 лет всё это послерабочее время высиживал?
Последней каплей стала очередная задача: срочно починить кому-то клавиатуру.
Кто в здравом уме и трезвой памяти будет просить починить клавиатуру? Особенно срочно.
Очевидно, что если срочно надо, то надо просто купить новую клавиатуру.
Кстати, у хороших админов всегда есть резервная на всякий случай.
Получив первую зарплату на новом месте, я осознал что мое резюме котируется.
Как котируемость резюме соотносится с первой зарплатой?
Котируемость резюме — это получить сотни офферов на резюме за день.
Получив первую зарплату на новом месте, я осознал что мое резюме котируется. Да, первое время работать девопсом — это сплошной нервяк. Я расправил плечи и успешно прошел собеседование на девопса в немецкую компанию.
Логика у автора есть вообще?
Т.е. этот админ получил первую работу, ему там тяжело и сложно, «сплошной нервяк» и поэтому он устраивается на вторую работу, чтобы в два раза больше охреневать.
Испытательный срок скоро закончится.
Не говори гоп, пока не перепрыгнешь. Это не законченное действе. Контора запросто может отказаться от услуг этого админа по результату испытательного срока.
взял практикумы Ребрейна в рассрочку
Это просто перл! Моя жизнь в корне изменилась, когда я взял практикумы в рассрочку и гречку в кредит!
Ребята, увольте вашего копирайтера. Его работа ужасна.
Я надеюсь, что качество ваших курсов гораздо выше уровнем, чем вот эта статья.
С уважением.
Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым 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, вбить в шаблон команды коммутатора и радоваться нормальному выводу от команд.
"Гарольд, скрывающий боль.jpg"
Это да =)
Я видел один из выходов: Sponsorware. Вкратце, вы далаете частный проект только для споноров на Github, например, но когда количество спонсоров перерастёт некоторое значение - проект переходит в open-source.
https://calebporzio.com/sponsorware
Буква или дух - я думаю, что юристы MongoDB и Elasticsearch лучше разбираются в американских законах =)
FSF и не должен судиться - у FSF другая миссия. Это сама компания должна судиться в том случае, если её права нарушены. Лицензия GPL просто предоставляет ей такое право, не более. Юристы MongoDB посчитали, что в суде против Amazon с текущей лицензией у них мало шансов и они поменяли лицензию.
А! Теперь понятно, спасибо.
Если нужен копилефт с отягощением на некомерческое использование, то такая лицензия уже есть - называется Academic Public License, которая, например, используется компанией OMNeT++: https://omnetpp.org/intro/license
Т.к. сама лицензия в Public Domain, то вы можете применять её к своему программному обеспечению.
А как вы думаете, нужно ли решать вопрос с компенсацией разработчикам открытого ПОДа, нужно. Раньше, до массового использования github/gitlab, это не было так очевидно, как мне кажется.
Я лично не вижу будущего у GPL v3 в том виде, в котором он сейчас есть.
Уже начались проблемы с тем, что SaaS vendor может использовать ПО GPL и при этом не следовать лицензии GPL и даже если код лицензирован по AGPL, где указано, что вы должны предоставить исходный код, если пользователи взаимодействют с ПО по сети, то это легко обходится просто вставив какой-нибудь прокси между AGPL ПО и пользователем.
И пока я вижу, что вместо поиска выхода из такого положения, FSF сейчас делает вид, что такой проблемы не существует.
Удивительно, как плохо люди понимают лицензию GPL даже в таких компаниях как Github.
Автор faker.js никому ничего не должен. Ни поддержки, ни работающей программы - ничего. Код предоставляется "как есть".
Пользователи его программы должны использовать свой форк в своём репозитории. В этом смысл GPL. А со своим репозиторием автор может делать всё, что угодно.
Для меня удивительно, что вообще существуют репозитории пакетов типа NPM.
Я вот смотрю на остальные репозитории пакетов свободного ПО - у них есть мейнтейнеры, которые фактически делают копию репозитория какой-нибудь программы и проверяют её работу на определённом дистрибутиве.
Мне кажется, если вы делаете коммерческое ПО на основе ПО со свободной лицензией, у вас должен быть свой личный репозиторий и свои мейнтейнеры. И всё ПО, что вы используете по свободным лицензиям, должно быть там.
Очевидно, что у Amazon, в случае использования такого подхода к пакетам свободного ПО, ничего бы не сломалось, и проблема была бы решена ещё на этапе обновления версии пакета в личном репозитории Amazon мейнтейнером.
Многие разработчики выкладывают продукт именно затем, чтобы его хорошенько протестировать, получить обратную связь и так далее.Для тестирования и обратной связи нет никакой необходимости открывать код по GPL.
Если для тестирования обязательно нужны исходные коды, то для такого обычно используют лицензии Sources-available, а не GPL.
GPL - это не та лицензия, если вам нужно только протестировать и получить обратную связь.
GNU-BY-NC - не существует и сомневаюсь, что будет существовать когла-либо, т.к. у FSF есть определённые понятия свободного кода. Т.к. в этом случае получается правовая коллизия, когда сторонний коммитер не имеет права продать свой же код, т.е. вы отбираете у него свободу, и поэтому эта лицензия не может быть свободной.
Яндекс.Практикум оказался про Практику, кто бы мог подумать!
Ну, об этом уже писали.
У админа точно есть высшее образование? А такое впечатление, что нет.
Приходишь в контору, видишь безобразие по электрике — вызываешь инженера-электрика — переделываете всё как надо.
Что он там 8 лет всё это послерабочее время высиживал?
Кто в здравом уме и трезвой памяти будет просить починить клавиатуру? Особенно срочно.
Очевидно, что если срочно надо, то надо просто купить новую клавиатуру.
Кстати, у хороших админов всегда есть резервная на всякий случай.
Как котируемость резюме соотносится с первой зарплатой?
Котируемость резюме — это получить сотни офферов на резюме за день.
Логика у автора есть вообще?
Т.е. этот админ получил первую работу, ему там тяжело и сложно, «сплошной нервяк» и поэтому он устраивается на вторую работу, чтобы в два раза больше охреневать.
Не говори гоп, пока не перепрыгнешь. Это не законченное действе. Контора запросто может отказаться от услуг этого админа по результату испытательного срока.
Это просто перл! Моя жизнь в корне изменилась, когда я взял практикумы в рассрочку и гречку в кредит!
Ребята, увольте вашего копирайтера. Его работа ужасна.
Я надеюсь, что качество ваших курсов гораздо выше уровнем, чем вот эта статья.
С уважением.