Гипотеза проста - хороший код ускоряет разработку. Меньше кода - быстрее поставка.
Так что я могу попросить разрабов сообщать на ретро или тех синке о подобных проблемах. И попрошу чтобы они сразу исправляли это, а не создавали доп тикеты.
Придумаю какой-нибкдь бонус небольшой за исправление минимум 1 такого места.
И добавлю сонар- буду смотреть на общий maintainability index для начала. А когда интегрирую DORA - посмотрю корреляцию.
Я получил код в плачевном состоянии, тут про метрики и бест практисы и говорить нечего. Скорее сборник примеров как делать не надо. По этому мне еще предстоит интегрировать все эти инструменты и метрики, выстраивать культуру и пайплайны.
Рад что у вас получилось. Хорошо если оно так работает.
Говорят, что доска отражает накопление знания и нельзя двигать тикеты назад. У вас же на доске отдельная колонка для тестирования. Как вы будете проводить доработку, если найден дефект? Перенесите обратно в разработку?
Если не разбивать о них лоб - это как раз про то, что они потеряли смысл.
Идеи не меняются. Их бывает толкуют не верно. Но скорее появится что-то новое, чем старое изменит смысл.
Скрам - не скрам, если его изменить. Но люди в скудоумии своём не могут в абстракции и дать другой идее новое имя. По этому как те зомби повторяют - Мозги.
Спасибо за статью. Подскажите пожалуйста, как адекватно измерять queue time? Метрики берутся со слов участников примерно. Или там нужен супер формальный подход к использованию трекера?
Какие метрики лучше измерять чтобы видеть разницу в 2х командах адекватно?
Попробуйте еще спросить бездушную машину: "Откуда появилась должность DevOps инжинер? Соответствует ли название должностной инструкции? Соответствует ли эта роль в принципе определению DevOps?"
За меня это все описали другие люди. Хоть тот же DevOps Topologies почитайте или Dave Farley с Кентом Беком или Р Мартина. Изучите что они говорят про ответственность разработчиков и процессы.
И если вам автор говорит что DevOps это культура - то это культура. Не надо переопределять термин. Администратор не может в культуру. Психолог и соц инжинер может.
Культуру вот пытались инженерить в некоторых странах. Делается это через PsyOps, СМИ, книги, систему обучения, кино.
Писать пайплайны и IaC любой может. Главное чтобы мотивация была.
Вот автор статьи приводит дора метрики. Все эти метрики будут нулевым, если разработчики не пишут код, не добавляют тесты, не пишут миграции, не умеют пользоваться версионированием апи. И какая бы там крутая автоматизация не была - все без толку.
К тому же все эти метрики существуют только на уровне команды. Отдельный человек их не делает. По тому что базовая единица поставки софта - команда.
С другой стороны если разраб делает это все - получается он девопс. Даже заменив библиотеку тестирования или миграции бд - ему придётся поправить пайплайн. Т.е. он уже вовлечен в автоматизацию. Выходит все разработчики - девопсы?
Там столько логических ошибок с этими дЕво-Псами, что если начну все расписывать, то придётся бросить работу и только и строчить статьи да ответы.
Культуру может вырастить только лидер поощряя определённое поведение, делая каждого в команде ответственным за результат. Когда разраб несёт ответственность за свою работу - он сам все автоматизирует и улучшает метрики. Ему не нужен костыль в виде пайплайнописца. Внешняя экспертиза про инфру пригодится. Счета за инфру пригодятся. Разрабы сами хотят все оптимизировать.
Забирать доступы - это не девопс. Это ото про безопастность. Возможно это и было нужно, но там много вопросов к исполнению и что дали в замен.
Я считаю это бесполезно, т.к. люди работающие с данными все равно их получат. Не из базы, так из какого-нибудь пресловутого даталейка.
Обычно это делают опсы которые считают что все вокруг овечки и не несут персональной ответственности перед работодателем. Хотя по факту, это как отобрать у дворника метлу.
Были у меня с такими ребятами долгие разговоры. Потом приходили юристы и объясняли что они не правы.
Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп.
Вам же дали задачу пайплайны писать и инфру, вы не нашли другого термина, кроме как ДевОпс. Так вот, в вашем случае, если остальные это Dev, то вы - Ops.
Метрики не принадлежат какой-то роли - это про команду.
И в поманде может быть Опс и много Дев, и каждый из них может писать пайплайн и инфру, тем самым влияя на метрики.
Не рассказывайте про значения заголовков вакансий которые придумали HR, а разберитесь в терминах для начала.
Эх, вы, дево-псы... как там DevSecFinBisOps поживает? Не пора ли уже похоронить этот термин? То о чем вы написали называется Continuous Delivery. Как следствие переименуем дево-псов в то, чем они являются - опсы обыкновенные и перестанем разыгрывать этот театр.
Те ребятки которые себя фулстеками считают и приходят на существующие продукты, они же не идут пилить существующий код на Java\php\python. Они начинают пилить свой "бэкенд" оборачивая существующие АПИ, делая тот самый SSR.
Это требует понимания что мы вообще в браузере выполняемся, и что фронт - это часть общего приложения и его надо рассматривать ВМЕСТЕ с бэком и БД и инфраструктурой.
А с СПА - можно закрыться в своем мирке и считать что вокруг ничего нет. Удел мидлов.
я не говорил что они отказываются от сахара вообще в пользу голого html.
Просто надо не запихивать целиком все в реакт, а делать виджеты. Да по другому чутка работает, но столько лишней сложности уходит. И htmx тут очень хорошо подходит. 99% веб приложений не нуждается в чем-то более сложном.
ССГ это хорошо, вот вы и вернулись к тому, о чем была статья изначально. Велком.
Только статья про Спринг, а не про JS фреймворки. И со стороны Спринга действительно проще делать SSG + htmx.
Так что я не понимаю в чем в принципе особая проблема..
Проблема в том что SPA - это дефолтное решение. Фронтендерам не приходит в голову мысль что можно НЕ делать SPA, не тащить стейт менеджмент, не тащить рутер и тп. Попробуйте, вам понравится.
Как говорил Фаулер: "if you can't change your team - change your team" :)
Правильно сделали. Нечего в чужом болоте тонуть.
Не вопрос. Пингану потом.
Гипотеза проста - хороший код ускоряет разработку. Меньше кода - быстрее поставка.
Так что я могу попросить разрабов сообщать на ретро или тех синке о подобных проблемах. И попрошу чтобы они сразу исправляли это, а не создавали доп тикеты.
Придумаю какой-нибкдь бонус небольшой за исправление минимум 1 такого места.
И добавлю сонар- буду смотреть на общий maintainability index для начала. А когда интегрирую DORA - посмотрю корреляцию.
Я получил код в плачевном состоянии, тут про метрики и бест практисы и говорить нечего. Скорее сборник примеров как делать не надо. По этому мне еще предстоит интегрировать все эти инструменты и метрики, выстраивать культуру и пайплайны.
Писать простой код могут не только лишь все.
Сочувствую. Но эта проблема в образе мышления. Кому-то изначально платили за строки кода. А потом он пришёл в продукт, а привычка осталась.
Сам сейчас таких переучиваю. Начну с выставления правильных kpi
Имею ввиду что метрики очень контекстно зависимы. Как понять почему команда А перформит лучше команды Б? На какие метрики и как надо смотреть?
Рад что у вас получилось. Хорошо если оно так работает.
Говорят, что доска отражает накопление знания и нельзя двигать тикеты назад. У вас же на доске отдельная колонка для тестирования. Как вы будете проводить доработку, если найден дефект? Перенесите обратно в разработку?
А null? Там же были проверки на нул в каждом методе? :)
У меня ровно такая же проблема с командой. Только теперь я могу на это повлиять.
Если не разбивать о них лоб - это как раз про то, что они потеряли смысл.
Идеи не меняются. Их бывает толкуют не верно. Но скорее появится что-то новое, чем старое изменит смысл.
Скрам - не скрам, если его изменить. Но люди в скудоумии своём не могут в абстракции и дать другой идее новое имя. По этому как те зомби повторяют - Мозги.
Спасибо за статью. Подскажите пожалуйста, как адекватно измерять queue time? Метрики берутся со слов участников примерно. Или там нужен супер формальный подход к использованию трекера?
Какие метрики лучше измерять чтобы видеть разницу в 2х командах адекватно?
Вводим новый грейд - попугай.
Попробуйте еще спросить бездушную машину: "Откуда появилась должность DevOps инжинер? Соответствует ли название должностной инструкции? Соответствует ли эта роль в принципе определению DevOps?"
Она вам без эмоций сама все и расскажет.
Ответ в духе "а чего добился ты?"
За меня это все описали другие люди. Хоть тот же DevOps Topologies почитайте или Dave Farley с Кентом Беком или Р Мартина. Изучите что они говорят про ответственность разработчиков и процессы.
И если вам автор говорит что DevOps это культура - то это культура. Не надо переопределять термин. Администратор не может в культуру. Психолог и соц инжинер может.
Культуру вот пытались инженерить в некоторых странах. Делается это через PsyOps, СМИ, книги, систему обучения, кино.
Писать пайплайны и IaC любой может. Главное чтобы мотивация была.
В том то и дело, что это так не работает.
Вот автор статьи приводит дора метрики. Все эти метрики будут нулевым, если разработчики не пишут код, не добавляют тесты, не пишут миграции, не умеют пользоваться версионированием апи. И какая бы там крутая автоматизация не была - все без толку.
К тому же все эти метрики существуют только на уровне команды. Отдельный человек их не делает. По тому что базовая единица поставки софта - команда.
С другой стороны если разраб делает это все - получается он девопс. Даже заменив библиотеку тестирования или миграции бд - ему придётся поправить пайплайн. Т.е. он уже вовлечен в автоматизацию. Выходит все разработчики - девопсы?
Там столько логических ошибок с этими дЕво-Псами, что если начну все расписывать, то придётся бросить работу и только и строчить статьи да ответы.
Культуру может вырастить только лидер поощряя определённое поведение, делая каждого в команде ответственным за результат. Когда разраб несёт ответственность за свою работу - он сам все автоматизирует и улучшает метрики. Ему не нужен костыль в виде пайплайнописца. Внешняя экспертиза про инфру пригодится. Счета за инфру пригодятся. Разрабы сами хотят все оптимизировать.
Забирать доступы - это не девопс. Это ото про безопастность. Возможно это и было нужно, но там много вопросов к исполнению и что дали в замен.
Я считаю это бесполезно, т.к. люди работающие с данными все равно их получат. Не из базы, так из какого-нибудь пресловутого даталейка.
Обычно это делают опсы которые считают что все вокруг овечки и не несут персональной ответственности перед работодателем. Хотя по факту, это как отобрать у дворника метлу.
Были у меня с такими ребятами долгие разговоры. Потом приходили юристы и объясняли что они не правы.
Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп.
Вам же дали задачу пайплайны писать и инфру, вы не нашли другого термина, кроме как ДевОпс. Так вот, в вашем случае, если остальные это Dev, то вы - Ops.
Метрики не принадлежат какой-то роли - это про команду.
И в поманде может быть Опс и много Дев, и каждый из них может писать пайплайн и инфру, тем самым влияя на метрики.
Не рассказывайте про значения заголовков вакансий которые придумали HR, а разберитесь в терминах для начала.
Эх, вы, дево-псы... как там DevSecFinBisOps поживает? Не пора ли уже похоронить этот термин? То о чем вы написали называется Continuous Delivery. Как следствие переименуем дево-псов в то, чем они являются - опсы обыкновенные и перестанем разыгрывать этот театр.
Просто, похоже, что скоро выкатят новую модель и надо будет ее как-то продать. Вот и будут рассказывать что новая версия понимает их на 20% лучше...
А поделитесь своими лайфхауами, как вы тяните оценки для больших и важных задач в wsjf. А то метод выглядит очень интересно и хотелось бы попробовать.
Там кажется в статье упоминается htmx...
В принципе то согласен. Но есть проблемка:
Те ребятки которые себя фулстеками считают и приходят на существующие продукты, они же не идут пилить существующий код на Java\php\python. Они начинают пилить свой "бэкенд" оборачивая существующие АПИ, делая тот самый SSR.
Это НЕ нормально.
Вы что, это же слишком сложно )
Это требует понимания что мы вообще в браузере выполняемся, и что фронт - это часть общего приложения и его надо рассматривать ВМЕСТЕ с бэком и БД и инфраструктурой.
А с СПА - можно закрыться в своем мирке и считать что вокруг ничего нет. Удел мидлов.
я не говорил что они отказываются от сахара вообще в пользу голого html.
Просто надо не запихивать целиком все в реакт, а делать виджеты. Да по другому чутка работает, но столько лишней сложности уходит. И htmx тут очень хорошо подходит. 99% веб приложений не нуждается в чем-то более сложном.
ССГ это хорошо, вот вы и вернулись к тому, о чем была статья изначально. Велком.
Только статья про Спринг, а не про JS фреймворки. И со стороны Спринга действительно проще делать SSG + htmx.
Проблема в том что SPA - это дефолтное решение. Фронтендерам не приходит в голову мысль что можно НЕ делать SPA, не тащить стейт менеджмент, не тащить рутер и тп. Попробуйте, вам понравится.