Прошу прощения, но вы звучите как сотрудник селектела. Под этим постом нет и двух тысяч просмотров, а вы уже накрутили 14 плюсов под свой комментарий. Если вы действительно сотрудник, должен вам сообщить, в своих накрутках вы не знаете берегов.
Что касается общения вне команды, вы уже проводили консультации и митапы с менеджерами, которые все это внедряли? Что интересного в этих митапах вы для себя нашли и как это помогает вашей работе?
Опуская вики и внутреннюю документацию, которая, я подозреваю, уже была. Смотря на вещи в перспективе, как описанная irintus система помогла вам получить софт лучшего качества?
Вероятно, в тинькове используется чуть иное понятие SLA. Можете пояснить подробнее, где-то в документах критерии SLA зафиксированы? Обозначена ответственность и какая-то система учета по этой SLA? И чем он отличается от KPI?
Давайте попробуем в качестве доказательства фотографию с монитора, где видно фрагмент кода любого сетевого IO. Можете отправить сюда или в личку, как вам комфортнее.
И сразу вопрос. Что конкретно имела в виду irintus, когда вводила SLA? Что имелось в виду под SLA и какие действия от вас это SLA требует?
Я прочитал ваши комментарии к той статье. Цитирую:
Прям есть:) Более того за ними никто не ходит и не заставляет этими бордами пользоваться, есть такие метрики только по одному из типов дашбордов качества:- уникальны пользователей: 147- просмотров 743Кажется неплохой результат, учитывая, что вряд ли туда заходят по одному, скорее всего эти борды открывают вместе с командой раз в какой-то период для ретроспективы или планирования. Также есть метрика по количеству новых дашбордов, в среднем это 10 дашбордов в месяц от пользователей, которые узнали о продукте из каких-либо внутренних источников.
Уважаемый, зря не вникали. Потому что никакой анкеты то нет. И на дашборде нет никаких индивидуальных метрик по людям, только командные. В "анкете" собирается информация о том, как люди ведут проекты в Jira, никому не интересно "Где, кто, с кем, сколько раз.".
Вы работаете в тинькове? Можете представить минимальное, не деанонимизирующее вас доказательство этому?
Если да, то я бы хотел задать пару вопросов, если вы не против.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
Мне показалось, что причины обозначены в самом начале статьи, где команды "должны были обратить внимание на качество своей работки". Если менеджер так говорит, значит он будет снижать тебе ЗП. Proof me wrong, что называется.
Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
А связь прямая - Testing in production и Observabilty это продолжение Continious Delivery. CD не заканчивается после успешного билда а CI не кончается после успешного развертывания на прод.
Прошу не путать подходы с DevOps, потому что DevOps это неправильный подход к CI/CD. Это отдельный холивар, который я бы хотел опустить.
Можно смело говорить, что в тинькове была серия автоматических тестов, возможно, даже был развернут дженкинс или тимсити с кучей серьезных тестов, которые должны проваливаться и должны проходить, каждый раз, когда софт идет в бой.
Манагер назвал конвейерное производство стихийным процессом.
Вот товарищ DrinkFromTheCup, в своем комментарии выше отлично просуммировал мои малосвязанные мысли.
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
Возьмем микросервисную архитектуру в тинькове за факт.
Часть команд будет заниматься одними сервисами, часть другими, где каждый сервис прикреплен к конкретной команде.
А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Сравнивать команды вне их предметных областей нельзя, но по тексту статьи, которую я прочёл, похоже, предлагается делать именно так.
Я думаю, что начальство взяло себе рычажок, которым будет рисовать надбавки и убавки, аргументируя тем, что тима фронтенда рисует 5 кнопок в день, а вы даже новую версию безопасной авторизации раз в пол года выкатить не можете.
Спасибо что уделили время моей токсичной проплаченной статье!
Надеюсь, деньги моего заказчика смогут улучшить положение дел в вашей компании!
Я, в свою очередь, тоже рад, что мой текст заинтересовал вас. Надеюсь, моя статья поможет вам сформировать альтернативный взгляд на вашу работу.
Именно так, рад что кто-то, кроме меня знает, что такое агиле.
Проплаченная компания...
Высосанная из пальца...
Прошу прощения, но вы звучите как сотрудник селектела.
Под этим постом нет и двух тысяч просмотров, а вы уже накрутили 14 плюсов под свой комментарий.
Если вы действительно сотрудник, должен вам сообщить, в своих накрутках вы не знаете берегов.
Похоже на то, зря я беспокоился.
Думаете таки да?
Как долго работаете в этой команде лично вы и каков возраст этой команды?
Что касается общения вне команды, вы уже проводили консультации и митапы с менеджерами, которые все это внедряли?
Что интересного в этих митапах вы для себя нашли и как это помогает вашей работе?
Опуская вики и внутреннюю документацию, которая, я подозреваю, уже была. Смотря на вещи в перспективе, как описанная irintus система помогла вам получить софт лучшего качества?
У вас есть пример успешного применения?
Вероятно, в тинькове используется чуть иное понятие SLA. Можете пояснить подробнее, где-то в документах критерии SLA зафиксированы? Обозначена ответственность и какая-то система учета по этой SLA? И чем он отличается от KPI?
Примеры из других команд тоже подойдут.
А нарушение SLA обычно подразумевает компенсацию, зафиксированную этим SLA. Иными словами, это KPI.
Давайте попробуем в качестве доказательства фотографию с монитора, где видно фрагмент кода любого сетевого IO. Можете отправить сюда или в личку, как вам комфортнее.
И сразу вопрос. Что конкретно имела в виду irintus, когда вводила SLA? Что имелось в виду под SLA и какие действия от вас это SLA требует?
Спасибо за похвалу. Эту статью я упустил, но с удовольствием прочитал сейчас.
Моя статья рассказывает про внедрение JSDD со стороны руководства, а эта указывает на лучшие практики JSDD для разработчиков.
Вместе получается отличный ликбез.
Я прочитал ваши комментарии к той статье. Цитирую:
Вы работаете в тинькове? Можете представить минимальное, не деанонимизирующее вас доказательство этому?
Если да, то я бы хотел задать пару вопросов, если вы не против.
Мне показалось, что причины обозначены в самом начале статьи, где команды "должны были обратить внимание на качество своей работки". Если менеджер так говорит, значит он будет снижать тебе ЗП. Proof me wrong, что называется.
Ну и конечно, итоги вы подвели абсолютно верно.
В моем материале много домыслов. Включая этот пункт тоже.
Это чистый домысел, выведенный из контекста.
Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
А связь прямая - Testing in production и Observabilty это продолжение Continious Delivery. CD не заканчивается после успешного билда а CI не кончается после успешного развертывания на прод.
Прошу не путать подходы с DevOps, потому что DevOps это неправильный подход к CI/CD. Это отдельный холивар, который я бы хотел опустить.
Спасибо за подсказку, кривые скриншоты заменил на цитаты.
Хочу за одно оговориться, что я не качу бочку на разработчиков, я качу бочку на магагеров.
Статья, которую опубликовала irintus похожа на свидетельство падение цивилизации.
Я читал и мне казалось, что её написали варвары, освоившие письменность. Они заняли места, ранее занимаемые гражданами более развитой цивилизации.
Эти варвары пишут тем же языком, но ни по содержанию, ни по форме они не напоминают ранее существующую, которую с гордостью уничтожили, упростили.
Я знаю, что труд, который опубликован даже на заборе, резонирует, и может обратить распространение вот этой вот опухоли.
Прочитав статью, выдержат ли разрабы тинькова бахвальство, с которым irintus написала свой доклад?
Можно смело говорить, что в тинькове была серия автоматических тестов, возможно, даже был развернут дженкинс или тимсити с кучей серьезных тестов, которые должны проваливаться и должны проходить, каждый раз, когда софт идет в бой.
Манагер назвал конвейерное производство стихийным процессом.
Вот товарищ DrinkFromTheCup, в своем комментарии выше отлично просуммировал мои малосвязанные мысли.
Спасибо, опечатку исправил.
Возьмем микросервисную архитектуру в тинькове за факт.
Часть команд будет заниматься одними сервисами, часть другими, где каждый сервис прикреплен к конкретной команде.
А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Сравнивать команды вне их предметных областей нельзя, но по тексту статьи, которую я прочёл, похоже, предлагается делать именно так.
Я думаю, что начальство взяло себе рычажок, которым будет рисовать надбавки и убавки, аргументируя тем, что тима фронтенда рисует 5 кнопок в день, а вы даже новую версию безопасной авторизации раз в пол года выкатить не можете.