Comments 189
Если на вопрос, то вы - манагер.
Что то я в самом начале застрял, можно пояснительную бригаду?
Цитирую абзац, из которого взята фраза на скрин-шоте:
Без единого подхода к метрикам соотнести команды между собой очень сложно. Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
Беда в том, что цитируемый менеджер не допускает даже мысли о том, что единой метрики для разных команд нет и быть не может.
У кого-то продукт менее дефектоопасный, у кого-то сезон более простых проектов, а кто-то и вовсе формально работает компании в убыток, прибирая за другими командами или открыв сезон охоты на легаси... да мало ли причин!
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
NB: я ни разу не автор - но я осмелюсь предположить, что автор имеет в виду что-то такое. Сам сталкивался и вроде бы что-то в этом понимаю... но мало...
А откуда взялось утверждение, что менеджмент по этим метрикам собирался сравнивать несравнимые команды? Есть какой-то список команд хотя-бы, чтобы делать выводы об невозможности их сравнить? Или менеджмент априори дураки и будут одни и те же требования предъявлять к машинам для перевозки пассажиров и сжиженного газа?
Утверждение - взялось из опыта. Даже если со стороны кажется, что две команды полностью идентичны как по скиллам, так и по характеру реализуемого продукта, - серьёзные отличия имеются. Основные причины я начерновую перечислил. Добавим наверх различия в манере управления и различное отношение к различным элементам рабочего процесса - и начинается пресловутый выпас котов...
Списка команд (и прочих околичностей) не нужно. Размазывание степени и характера нагрузки - это очень здравая тактика. То есть в сколь-либо крупной фирме поймать момент, когда все занимаются схожими задачами со схожей... как это назвать по-научному - хз... счислимостью, что ли, - малореально. Это тупо не выгодно ни бизнесу, не терпящему просадок, ни разработке, жаждущей разнообразия задач. Да и тот же SCRUM каждая команда понимает несколько по-своему. Это ж не Десять Заповедей, разные части ритуалов выполняются не везде и неодинаково.
Не то чтобы менеджеры априори дураки. Просто считать, что "для того, чтобы управлять чем-то, надо в этом досконально разбираться" перестало быть принято.
В тех редких случаях же, когда руководство осознаёт наличие потребности "управлять, понимая", - кадры, одинаково хорошо смекающие И в кодинге, И в менеджменте, привлекаются в первую очередь на техлидские, архитектуростроительные, etc-etc позиции. Причём, с меньшим головняком и на куда бóльшие деньги.
А на [якобы чисто] менеджерские позиции приходится набирать деятельных юнцов и юниц, вызубривших всякой фигни на пару сертификатов и убедительно умеющих пускать пыль в глаза. И надеяться, что, во-первых, вольются в общий флоу компании, а во-вторых, наберутся уму-разуму по технической части. И станет хорошо.
Беда в том, что хорошо треплющийся юнец со стопкой сертификатов не умеет вливаться да ума набираться. Он УЖе уверен в том, что раз у него сертификат в зубах и должность под ххх, - весь мир у него в кармане и все должны под него гнуться. По должностным инструкциям обязаны. Спеца на договоре то так просто не уволить, а косяки менеджмента доказываются тяжко и кошмарно...
И начинаются трения со столкновениями, до искр и хлопаний дверьми.
Я отдаю себе отчёт, что я даже не юнец с сертификатом, поэтому панически боюсь и избегаю таких позиций. А если неминуемо засасывает куда-то рядом - в меру своих куриных мозгов пытаюсь как-то вычленить и реализовать наименее отвратительный вариант развития событий. Не навредить.
Но %!., видимо, хреново стараюсь. Старался...
Ну конечно же не надо всегда досконально разбираться чтобы чем-то управлять. Однако стоит разделять ситуации, когда допустимо чем-то управлять без досконального понимания, а когда нет.
Вот школьник управляет своим смартфоном - думаете он досконально разбирается? Как это обеспечили? Просто дали ему некие понятные правила и ограничения, в которых он управляет, чтобы в ногу себе не стрелял.
Отдельная история - страдания технических специалистов, продолжающих есть кактус работать с некачественным менеджментом. Я не понимаю, в мире нет менеджмента качественного? Или их туда не берут? Или им лень поискать нормальный менеджмент?
Один момент на мой взгляд есть значимый. Думаю, в РФ более развита техническая школа, чем менеджмент, из-за чего есть перекос. Но всё равно, каждый сам решает, либо страдать, либо пробиваться в компании с качественным менеджментом.
Вы знаете, у меня слишком хорошее настроение, чтобы дёргаться на Ваше очевиднейшее насилие над логикой. Попробуем сыграть на Вашем поле.
Когда школьник управляет своим смартфоном, он обычно не разбирается ни в смартфоне, ни в себе. Поскольку задачи, для которых смартфон был выдан, школьник не выполняет. А вместо этого дуется в ПУБГ Мобайл или что там нынче модно.
Напомню, у нас в контексте статьи преследование стратегических задач и организация процесса. Школьник с мобилой - это хреновый пример что стратегии, что организации.
Про технарей vs менеджмент. Вы умудрились не заметить моё объяснение. Ладно, с кем не бывает, об мои тексты и не такие глаза ломались. Ладно, попробуем по-Вашему. Вы предлагаете бросить рабочее место и начать мотаться как в проруби (по паре месяцев на фирму, чтобы в рамках испыталки всё разведать) и окончательно испортить себе трудовую книжку? А что делать, если в выбранной сфере всё уже прозондировано и адекватов там нет? "пфффф изи меняй стэк переучивайся с нуля", так Вас понимать? Вы сами то осознаёте, какой оверкилл предлагаете?
Затрудняюсь вести диалог, если вы даже абстрактного школьника со смартфоном первым же сообщением заклеймили.
Если вы выбрали кактус сферу, в которой в принципе нет адекватного менеджмента в части работы с ИТ (такое бывает), и не хотите её менять, потому что это кажется оверкиллом, то... это ведь просто ваш выбор, а не повод делать выводы про менеджмент вообще где бы то ни было?
В кровавом энтерпрайзе законы Мёрфи таки действительно работают. :-(
Да, законы Эди Мёрфи
Лучше пусть будет иллюстрацией законов Мёрфи, чем Дилберта, чесслово.
Тогда через законы Мёрфи легко доказать что <вставьте роль> априори дураки.
Вы не находите это неконструктивным?
Вот сейчас бы ещё докапываться до законов Мёрфи. Если кто-то может смотреть в завтрашний день, но делает этого, то он всё равно может это делать, а не априори слеп.
Тогда через законы Мёрфи легко доказать что <вставьте роль> априори дураки.
Не очень понял, продемонстрируйте примером, пожалуйста.
Понимание законов Мёрфи в кровавом энтерпрайзе позволяет просто более эффективно работать:
подстилать соломку вовремя, делать "эшелонированную фильтрацию" всякого (делаем 99% процентов работы каскадами простой/сложной автоматики, но понимаем, что условный 1% ручного труда обязательно останется => надо давать возможность ручного управления), иметь планы А/Б/В на разные случаи, ну и так далее.
Ну и понимание того, что вот всё вышеперечисленное в простых случаях не нужно, тоже полезно. Ну, что законы Мёрфи имеют свою область применения.
В данном случае — очевидно, что при появлении таких метрик в подразделении, надо перестать сразу отбрасывать мысль о смене работы.
Спасибо, опечатку исправил.
Возьмем микросервисную архитектуру в тинькове за факт.
Часть команд будет заниматься одними сервисами, часть другими, где каждый сервис прикреплен к конкретной команде.
А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Сравнивать команды вне их предметных областей нельзя, но по тексту статьи, которую я прочёл, похоже, предлагается делать именно так.
Я думаю, что начальство взяло себе рычажок, которым будет рисовать надбавки и убавки, аргументируя тем, что тима фронтенда рисует 5 кнопок в день, а вы даже новую версию безопасной авторизации раз в пол года выкатить не можете.
Спасибо, опечатку исправил.На хабре можно куски текста вставлять через цитирование: <blockquоte>цитата </blockquоte>
Очень трудно читать скриншоты с лишними, и просто криво подчеркнутыми словами. У вас где-то вставлены скриншоты как цитаты, а где-то наклонный текст, типа цитата. Каждый абзац разного формата. То скриншоты из Iphone на весь экран, то буквы мелким шрифтом, читать очень тяжело вашу статью.
Понял, что у вас горит на какого-то PO в тинькове страховании, но я думаю, что есть и нормальные команды, куда эта дама не добралась. Скажем так, я видел во многих крупных компаниях — как хорошие команды, так и токсичные. И это не значит, что вся компания токсичная.
Спасибо за подсказку, кривые скриншоты заменил на цитаты.
Хочу за одно оговориться, что я не качу бочку на разработчиков, я качу бочку на магагеров.
Статья, которую опубликовала irintus похожа на свидетельство падение цивилизации.
Я читал и мне казалось, что её написали варвары, освоившие письменность. Они заняли места, ранее занимаемые гражданами более развитой цивилизации.
Эти варвары пишут тем же языком, но ни по содержанию, ни по форме они не напоминают ранее существующую, которую с гордостью уничтожили, упростили.
Я знаю, что труд, который опубликован даже на заборе, резонирует, и может обратить распространение вот этой вот опухоли.
Прочитав статью, выдержат ли разрабы тинькова бахвальство, с которым irintus написала свой доклад?
А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Ну, по количеству закрытых задач. Некоторые особенно эффективные менеджеры меряют количество написанного кода. Но это еще на уровень выше, чем у irintus.
Похоже на сообщение, которое должно было попасть в личку, но зачем-то оказалось на Хабре
CI/CD и тестирование на продакшене это стихийный процесс. Стопроцентное покрытие кода – стихийный процесс. Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.
А кто автор всей фразы то? Я что то такого не вижу
«Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?»
Да, это называется CI/CD
Что?
Я думал, что один далеко не всё понял.
Так-то боль автора понятна, часть претензий тоже. Но он настолько активно строил соломенное чучело, что необоснованных утверждений и откровенного передёргивания получилось не меньше, чем объективных моментов.
Можно смело говорить, что в тинькове была серия автоматических тестов, возможно, даже был развернут дженкинс или тимсити с кучей серьезных тестов, которые должны проваливаться и должны проходить, каждый раз, когда софт идет в бой.
Манагер назвал конвейерное производство стихийным процессом.
Вот товарищ DrinkFromTheCup, в своем комментарии выше отлично просуммировал мои малосвязанные мысли.
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
Манагер назвал конвейерное производство стихийным процессом
А есть цитата конкретная? Я вот нашёл только
Практика разбора дефектов была у многих команд, но носила стихийный характер
И какая связь между CI/CD и сбором статистики по дефектам в проде?
Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
А связь прямая - Testing in production и Observabilty это продолжение Continious Delivery. CD не заканчивается после успешного билда а CI не кончается после успешного развертывания на прод.
Прошу не путать подходы с DevOps, потому что DevOps это неправильный подход к CI/CD. Это отдельный холивар, который я бы хотел опустить.
Вы специально вопрос игнорите? Приведите цитату, где автор назвала "конвейерное производство стихийным процессом"? Без домыслов только, что можно рандомно менять "разбор дефектов" на "CI/CD"
Вы хотите опустить холивар, но ставите равенство между CI/CD и поиском дефектов на проде?
Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
В исходной статье речь идет о багах на проде. То есть вы считаете, что у них никогда не было багов на проде? На чем основано такое нелогичное предположение? Они даже у Гугла есть.
Хтонический ужас провисел почти сутки, не заминусованный
"А мужики-то не знают!" (с)
Понимаю боль автора от эффффффективных менеджеров... но текст вырви глаз...
Исходная статья https://habr.com/ru/company/tinkoff/blog/684608/ и перечисленные в ней подходы вполне адекватны, чего не могу сказать об этой статье. CI/CD не является панацеей при тестировании. И конечно никто CI/CD сжигать не предлагал в оригинальной статье, там даже слова такого нет.
Мне кажется, автор во многих местах, где упоминается "CI/CD", имеет ввиду монитринг и трекер ошибок, типа Sentry/Rollbar/New Relic. Тогда это имеет смысл.
CI, как метрику, можно использоваться разве что для отслеживания "производительности" тестов (аля "запуск тестов занимает много времени, давайте оптимизируем").
Конечно, чтобы подстроиться под KPI, люди кое-чо придумают, но пусть Irintus узнает об этом сама.
Ухахахахааааааааа, дааааа, это будет весёлый сюрприз, плохо диагностируемый и ещё хуже наказуемый. Я прям чую знакомый аромат!
Ведь у него будет прям юридически выверенное обоснование - и "пересесть" с него обратно будет из-за этого очень, очень затруднительно...
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
По-хорошему, эта метрика - "погода на Марсе", у которой могут быть наиудивительнейшие причины.
Неожиданное "покраснение" этой метрики - это повод для постмортема (человеческого, с полноценным разбором, откуда "наросло" и как впредь "предотвратить"), а не для битья линейкой по рукам кого попало.
Но и не повод для гордости.
(и неожиданное "позеленение" - ТОЖЕ повод для разбора!)
Статья дельная.
Увы, как я уже многократно ныл ранее, поскольку IT нынче перестал быть уделом серьёзных дядек с высшим образованием и стал рассадником нигилистов, который посоперничает по градусу деградации с произвольным форумом игроков в DOTA 2, - более адекватный подход УЖЕ НЕВОЗМОЖНО РЕАЛИЗОВАТЬ.
И даже потеоретизировать о нём.
Потому, что вездесущие и очень голосистые продавцы вагинальных чаш (откуда, чёрт возьми, они тут...) да утратившие здравый смысл и опыт человеческого общения любители побравировать репутацией очень быстро набегут и попытаются отнять Ваше время впустую.
Берегите себя. Не ведитесь. N.G.U.N.S.
Ох уж эти дедовские методы, до сих пор встречающиеся на местах. Тоже достало.
Битье линейкой вообще штука контрпродуктивная. Да, чисто по человечески хочется иной раз "наказать мерзавцев", но это именно что эмоции, пользы от них никакой, зато вред огромный, поэтому профессионалы держат себя в руках.
Это просто два разных подхода: конкурентный и командный. Многим разница не особо очевидна, но ее нужно понимать, и отдавать себе отчет, какого подхода следует придерживаться, и почему.
В первом важнее индивидуальный результат. Его можно усилить за счет упорного труда - тяжелый, сложный, для многих нереальный вариант: настоящих профессионалов всегда мало. Но можно усилить и за счет группы: разрывая коммуникации в группе, разрушая любые эффективные связки, педантично ослабляя конкурентов любыми доступными методами, чтобы на их фоне выделялся даже посредственный результат.
Во втором важнее групповой результат. Его также можно усилить за счет упорного труда: единицы профессионалов тащат основную нагрузку. И также можно усилить за счет группы: выстраивая более эффективные коммуникации в группе, усиливая координацию, создавая эффективные связки внутри группы, выявляя и удаляя деструктивные звенья.
Мне и моим многим знакомым приложение банка Т спамит пушами с мольбами о том, что им срочно нужны айтишники.
Впрочем, в банках везде ужас, но я надеялся, что хоть в Т он не такой.
Из общего тона статьи у меня создалось ощущение, что вы негативно настроены (либо к автору предыдущей статьи, либо к разработке в Тинькове, либо к организации). Но почему — непонятно.
Не могли бы вы уточнить:
- вас не устраивают описанные в предыдущей статье новвоведения (а до этого все было норм), качество отдельного продукта компании, вообще все продукты или что-то другое?
- Какое отношение вы имеете к Тинькову: участвуете в разработке, пользуетесь их продуктами или что-то еще?
Я прочитал статью и ничего не понял. Как будто статью написал Олег.
Это как будто стенограмма (несуществующего) видео "Моя реакция на "Сказ про то, как мы метрики качества внедряли".
работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно
Это же сарказм? Не, ну, правда же? А?
А почему бы и нет?
На одном из моих прошлых мест работы и вовсе просто титанических объёмов проект существовал как единый мастер-репозиторий.
В который, если я правильно помню, после минимальных смоук-тестов заливались фичи, с последующими регулярными проверками мастера на регресс.
И из которого же потом выделялись ветки очередных релизов.
И ничего, никто не умер.
Правда, это требует совершенно нетипичной коммитной дисциплины.
Зато, вот честное комсомольское, рыться в их коде было сплошным удовольствием даже для меня, гуманитария до костей мозга.
Намного приятнее, чем при несколько более традиционном подходе "накоммитить в N веток, а потом итеративно эти ветки "женить". Потому, что коснись что - в карте коммитов и веток, больше напоминающей схему московского метро, а не репозиторий, концов не найти.
И шлак в релиз в том мега-проекте попадал скорее из-за пренебрежения здравым смыслом в иных процессах.
страшные ченжи - ревью в отдельной ветке, черри-пик в мастер.
не страшные - коммит в мастер, ревью и фиксы ревью тоже в мастер
Смотря что считать "страшными" чейнджами, к слову. По моим наблюдениям, при таком подходе "страшным" может быть только рефакторинг какой-то сложной (и объёмной) логики, которую и залить по частям нельзя (не пройдёт смоуки), и не заливать по частям нельзя (тупо слишком много рефачить за один заход).
Коммитная дисциплина здорово облегчает жизнь и уменьшает градус "страха" потому, что даже в едином репозитории видно не только ЧТО изменилось, но и ЗАЧЕМ.
Если бы ещё "наверху" не воровали мою документацию на старый код, а писали свою, - можно было бы и на ходу отделять фичи от незапланированных перекосов логики и прочих ужасов.
Если действительно нужно слишком много всего без мержа в транк делать то никто не мешает сделать ветку. Практика показывает что из 1к разработчиков это нужно двум одновременно:) все остальные прекрасно живут на мастере
Работа в мастере (без хотя-бы минимального ревью) противопоказана в случае если в команде есть хотя-бы один человек, не разбирающийся по-нормальному, в работе гита (не важно - через консольные команды или через любимую gui-утилиту).
Странный вопрос. Если разработчику страшно мержить то что он написал без предварительного показа то и ченж страшный.
"Страшные" могут быть, на мой взгляд, начиная с MINOR, согласно https://semver.org/
А представьте себе проект, где один разработчик. Это все еще личный проект, или где? Я в таком работал пару раз, и ничего, все успешно развивалось несколько лет. Не буду утверждать, что это идеально (как раз зачастую не хватает ревью, с целью посмотреть свежим взглядом, не упустил ли я более простые способы сделать тоже самое), но такое бывает и работает. Все равно ведь я знаю, что все коммиты мои. Вот зачем мне в такой ситуации скажем pull request? Вроде уже не надо. Ну так и многое остальное очевидно можно упростить.
Совсем забыл влезть с ответом в этот вопрос.
А как вы ревью делаете?
В личных проектах - никак. Совсем.
С чем-то серьёзным, где реально кодить надо было, - не доводилось вляпаться в ситуацию, когда PlayNite (и его основа .net) допускал больше одного варианта реализации нужной мне (крайне минималистичной) логики, знай себе, копируй-вставляй-передёргивай-тестовую-сборку. Да комментами присыпать погуще, чтобы когда встанет потреба что-то подпереть - не искать концов и не сидеть мордой в клаве, пытаясь вспомнить, а зачем я вообще делал то-то и сё-то.
С модами - почти аналогично. Мало какой модкит даёт серьёзно отличающиеся варианты для выбора.
По работе же... тоже никак. Не кодер я. Не кодер. Но.
Моему перу по состоянию на 2016 год принадлежало порядка 10% актуальной внутренней документации по игромеху "танков". Что неприлично много для, по сути, сраного саппортёра среди 1.5к куда более закалённых и отточенных кодоворотов. И судя по тому, что мои черновики регулярно тырили себе программисты да тестировщики, получалось неплохо.
Процесс выжимания документации из сорсов крайне близок к процессу код-ревью, с моей точки зрения.
В обоих случаях производящий работу должен как очень хорошо ориентироваться в чужом коде, так и очень хорошо понимать, какой результат от работы этого кода ожидается.
И в обоих случаях "коммитная дисциплина < > парадигма использования одной или нескольких веток для регулярной разработки". (чёрт, спросонья не в ту сторону знак сравнения поставил...)
(что же творилось на код ревью у истинных программистов наших - прошу понять и простить, это совершенно не моего ума дело, хехехехехе...)
Мой хороший знакомый, фактически друг, работает сейчас в конторе, где они делают рецензирование post-merge. То есть, сперва разработчик пишет, потом сам тестирует, потом сливает, а потом оно рецензируется. И таки оно много лет так работает (в trading). Понятно дело, что люди там не совсем с улицы набраны.
в карте коммитов и веток, больше напоминающей схему московского метро, а не репозиторий
А если ветки ребейзить перед мерджем, то будет история коммитов здорового человека.
Может да, а может и стоит иногда выйти за пределы парадигмы гитфлоу (которая не является серебряной пулей и тащит за собой кучу проблем) и внимательно посмотреть по сторонам?
Но это неточно.
Кому сарказм, кому trunk based development.
А что не так? Любые гит-флоу организуют работу команды вокруг одной ветки, куда все по итогу сливают свой код. А все эти фича-ветки простор помогают в этом.
- А зачем нам джира, когда есть VCS? Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
Человек, который обнаружил баг - это пользователь системы. Ему тоже предложите пул реквест сделать?
В статье, конечно много правильных мыслей, но подача слишком однобокая.
Уберите эмоции и получится дельная статья с конструктивной критикой
Заменить прямой учет багов на проде на какие-то метрики CI/CD - это конструктивная критика?
Или может предложение использовать GIT для регистрации дефектов вместо JIRA?
Или креативная идея обязательно применить Trunk Based работу с 1 веткой не вдаваясь в реалии конкретной команды, продукта и требований к нему - тоже конструктив? Остальные подходы ведь придумали злые эффективные менеджеры, даже Scaled Trunk-Based.
Бывало и у меня хтонический ужас висел - куда без этого при сидячей работе
«Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.»
Во Вторую мировую войну венгерскому математику Абрахаму Вальду, работавшему в нью-йоркской лаборатории SRG, поручили найти решение важной задачи. Не все американские бомбардировщики возвращались на базу. А на тех, что возвращались, оставалось множество пробоин от зенитной артиллерии и истребителей, но распределены они были неравномерно: больше всего на фюзеляже и прочих частях, меньше в топливной системе и намного меньше — в двигателе. Значило ли это, что в пробитых местах нужно больше брони? Вальд ответил: нет, исследование как раз показывает, что самолёт, получивший пробоины в данных местах, ещё может вернуться на базу. Самолёт, которому попали в двигатель или бензобак, выходит из строя и не возвращается. Поскольку попадания от вражеского огня на самом деле (в первом приближении) распределены равномерно, укреплять надо те места, которые у вернувшихся в массе наиболее «чистые».
На мой взгляд есть простой показатель, который показывает куда движется проект - в сторону деградации (что бывает чаще всего), или в сторону улучшения. Показатель, конечно, не 100% верный, потому что все можно подделать. А чтобы подделать его было сложнее - я бы вообще не говорил команде, что его замеряю.
Показатель простой. Раз в неделю/месяц, берутся все задачи в трекере, и считается, какой % из этих задач был типа "ошибка/баг".
Соответственно, если каждый месяц % багов от общего количества задач растет - это тревожный сигнал. Раз встречал проект, где багов было 80% всех задач. Т.е. команда практически все время только и делала, что правила бесконечные баги (проект был без авто-тестов и CI/CD), показательно, что проект потом переписывали с нуля.
Конечно, этот показатель сработает, если в команде принято за правило все изменения по коду делать через создание задачи в трекере. Потому что, опять же, встречал команды, где была какая-то фобия на создание задач об ошибках. Как будто если задача не создана - то и ошибки вроде как и не было.
Вообще все упирается в компетентность менеджмента, и его вовлеченность в проект. При желании все решается и довольно просто. Например, чего не встречаю, а хотелось бы - чтобы программистов больше делили по разным сервисам, которыми занимались бы только они. Соответственно по количеству ошибок в том или ином сервисе будет легко понять, кто пишет код нормально, а кто тяп-ляп и за кем надо постоянно перепроверять и доделывать.
Ради интереса - % это доля от числа задач, иди доля от числа потраченного времени?
Грубо говоря, хуже ли 10 багов по 5 минут чем 1 баг на час?
Если проект конечный, то к завершению все фичи сделаны, а вот баги ещё есть. В вашей метрике с приближением проекта к завершению процент бардака багов будет расти, хотя ситуация не обязательно ухудшается.
Показалось, что вы спроецировали моменты из статьи на какой-то свой прошлый негативный опыт.
Какая чушь. Кто это плюсует? Это проявление какого-то стадного инстинкта против Тинькофф-банка и менеджеров, независимо от сути написанного? Человек грубо высказывается в адрес другого человека на основе своих домыслов, нестандартных подходов к разработке, и бессмысленных высказываний.
(не имею никакого отношения к банку Тинькофф и не высказываюсь в защиту их бизнес-решений, говорю исключительно о логике)
Без единого подхода к метрикам соотнести команды между собой очень сложно
У вас же есть CI/CD, значит и метрики есть.
Вы подменяете понятия и с этим спорите. Автор исходной статьи говорит о том, что не было единого подхода к анализу метрик при их наличии, это понятно из контекста.
а какой команде стоит обратить внимание на качество своей разработки
А вы считаете, что в принципе не бывает команд, которым стоит обратить внимание на качество своей разработки? А если бывают, то как это определить?
Irintus первым делом начала смотреть на то, что уже работает. Ведь зачем приходить в компанию с набором готовых, рабочих практик
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".
Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?
Да, это называется CI/CD
Общепринятое понимание "CI/CD" заканчивается после deployment. Поэтому статистика по ошибкам, которые появились после deployment на прод не называется CI/CD.
Практика разбора дефектов была у многих команд, но носила стихийный характер.
Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.
В исходной статье речь идет про разбор (анализ) человеком ошибок на проде, найденных пользователями или другими сотрудниками организации, а также тестировщиками на тестовом сервере. Вы почему-то относите к этому автоматизацию процесса разработки и приписываете автору, как будто она это сказала. Вдумайтесь в безумие этой фразы.
Юнит тесты, интеграционные тесты и тесты на продакшене, все слиплось…
В процитированном фрагменте из исходной статьи не идет речь про юнит-тесты, при чем тут они?
Удобство, интеграция с IDE, CI/CD. Незнакомо… непонятно...
Непонятно здесь только вам. В исходной статье говорится, что это команды по-разному обозначали такие задачи в трекере. "мы насчитали шесть разных подходов к разграничению дефектов".
График закрытых дефектов должен быть приближен к графику заведенных
больше нельзя заводить TODO, и обсуждения, нельзя писать RFC, иначе графики не совпадут.
С чего вы взяли, что любая задача в трекере в их компании считается дефектом? По каким причинам это вообще можно было предположить? Такого ни в одной компании не бывает, всегда есть задачи с багами и есть задачи на новую функциональность, которые не считаются багами.
Новичок задает вопросы? Так делать нельзя, график вверх – плохо.
У вас на каждый вопрос новичка заводится задача с багом? Дело ваше конечно, но у остальных не так.
Разработчики, новенькие и техническая поддержка не должны общаться напрямую, это поднимает линию вверх, а вверх это плохо.
Каким образом прямое общение кого бы то ни было связано с количеством задач с багами, по которому строится этот график?
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
Именно большое количество говорит о том, что в процесс не вовлечен программист, потому что написал и даже простые кейсы не проверил. Либо о плохом качестве кода, который разваливается при любом изменении.
команда тестирования не пропускает релиз потому, что получит по башке из-за «дефектов на проде»
Если команда тестирования нашла баг, нафига пропускать его на прод?
Вся сила CI/CD в том, что, работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно.
Что за чушь? Общепринятый подход это отдельная ветка на задачу. В main ничего не пушится напрямую, на это прямо ставится запрет в настройках системы управления кодом.
Такой подход неявно предполагает, что прод и дев это два разных пайпа или бранча, которые отдельно поддерживаются.
Нет, это вы так предполагаете. В исходной статье говорится про тестовые среды, а не про ветку для разработки. Вы не знаете, что такое сервер для тестирования, на который выкладывается задача для проверки перед мержем в main?
станут звучать рациональные вопросы.
А зачем нам джира, когда есть VCS?
Если у вас маленькое приложение на 100 файлов, единственными пользователями которого являются программисты, то вам низачем.
Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
Финансист, который работает во внутренней финансовой программе, может сделать пул реквест? Даже если он изучает программирование по вечерам, никто ему не даст доступ к кодовой базе проекта.
Это не рациональные вопросы, это чушь какая-то.
было создано 530 дашбордов качества
когда ни работники, ни начальство не понимает, зачем нужны метрики
Это вы похоже не понимаете, что бывают ИТ-отделы с десятками команд и сотнями разработчиков.
Вывод. Автор не знает, что такое тестовая среда, зачем нужны таск-трекеры, как организована работа в команде в большинстве продуктовых компаний, при этом лезет поучать других в грубой форме.
В целом согласен
Если команда тестирования нашла баг, нафига пропускать его на прод?
Такое возможно если баг не существенный, а какая-то функциональность срочно нужна
Это понятно, в таких случаях делается обсуждение с лицами, принимающими решение, и по результатам пишется комментарий в задаче "Такую-то ошибку решили исправить после выкладки, задача на исправление такая-то". К тестировщикам нет претензий, и им нет необходимости упираться рогом и не пускать релиз на прод.
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".
Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
До изменений они там уже были:
в каждой команде (были) свои процессы и подходы к метрикам - из "Сказ про то, как мы метрики качества внедряли"
Далее, по тексту "Сказа", менеджер уничтожил старые метрики и сделал новые.
Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера
А автор владеет информацией, что там у компании и разных команд было?
Я спрашивал, но не получил ответа на вопрос, насколько автор знаком с внутренней ситуацией.
Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
У автора тут претензия к выражению "стихийный характер". В той статье оно относится к практике именно разбора дефектов, то есть как раз к тому, что они были, но анализировались недостаточно. Она не о том, что одни метрики заменили на другие, а о том, что по существующим метрикам добавили анализ.
Мы с вами разные статьи прочитали?
Я прочитал статью "Сказ про то, как мы метрики качества внедряли", где топ-менеджмент поставил задачу руководителю по обеспечению качества, Ирине, выработать единую метрику, чтобы сравнить команды разработки между собой.
Ирина выработала набор метрик, который теперь является единым всей компании - теперь это метрики по дефектам.
Если раньше какая-то команда оценивалась по Scrum метрикам, то теперь Scrum метрики не используются для оценки эффективности команды, теперь используются новые метрики по дефектам от Ирины.
Автор данной темы вероятно имеет ввиду, что введение новых метрик приведет на длинной дистанции к ухудшению качества разработки. Матерые разработчики разбегутся, а у новичков будет ориентир исключительно на показатели. Обычно такие "новшества" подразумевают под собой сокращение расходов. Ну, а что означает изменение вектора компании на сокращение расходов и так все знают..
Про Scrum метрики или замену одних метрик на другие в той статье ничего нет.
Вот что там есть.
"Практика разбора дефектов была у многих команд, но носила стихийный характер."
"Так мы поняли, что статистику дефектов, ее анализ, постановку целей по улучшению и SLA мало кто делал."
"[в существующих подходах] мы смогли выделить четыре варианта разделения дефектов теста и прода. По полю: Type, TI Environment, Bug Environment, Bug Category."
"Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным."
То есть данные были, статистики по ним не было, после этого появилась с минимальным изменением в существующих процессах.
В самом начале
При этом в каждой команде свои процессы и подходы к метрикам.
Т.е. у каждой команды были свои метрики.
Практика разбора дефектов была у многих команд
У многих, но не у всех. У оставшихся не было практики разбора дефектов. Но так как метрики были в каждой команде (см. предыдущую цитату), значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.
Что произойдёт с метриками команд, у которых были другие метрики? Риторический.
Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным.
Это по словам менеджера Ирины =) У нас нету реакции программистов на эти нововведения. Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Нет, возможно метрик, связанных с дефектами или эффективностью, у них просто не было. Так бывает, команда просто пилит задачи.
Что произойдёт с метриками команд, у которых были другие метрики?
Новые метрики добавятся к существующим, это самый вероятный вариант. Предыдущие метрики были зачем-то нужны, новая их полностью не заменяет.
У нас нету реакции программистов на эти нововведения.
Это не значит, что надо это додумывать и высказывать грубости в адрес менеджера, как в этой статье.
Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
Вы похоже не понимаете, что такое дашборд. Это автоматизированный график, который строится по метрикам небольшим скриптом. Собственно, их для этого и собирают, чтобы потом вывести в каком-то наглядном виде и проанализировать. Раз он автоматизированный, то его никому вести не надо, он строится сам при открытии страницы. А данные для него они заносили и до введения новой статистики (поля Bug Environment и т.д.).
он строится сам при открытии страницы
В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.
Дашборд создаётся вручную, к нему указываются фильтры для Jira, ключи проектов, типы задач и прочее. Всем этим фильтрам надо следовать и добавлять новые в дашборд, если они появились.
Я про это ведение дашборда.
У них уже 625 дашбордов и каждый месяц количество дашбордов увеличивается на 30 (10 качества+20 базовых).
Всем этим фильтрам надо следовать и добавлять новые в дашборд
Я не понимаю, что вы подразумеваете под словом "следовать". Фильтры заданы, им следует скрипт, который строит запрос к данным. Что вы хотите добавлять в дашборд, тоже непонятно. У нас есть конкретные фильтры, которые нас интересуют, зачем туда добавлять что-то постороннее. Дашборды общие на команду, и с большой вероятностью занимается ими тимлид, которому за управление командой компания платит деньги.
Судя по видео, многие дашборды строятся на несколько месяцев, и возможно поэтому надо их адо раз в месяц обновлять на новые даты. Также имеет значение период, на сколько месяцев он строится. Построили один дашборд на 3 месяца, потом решили "Не, что-то мало, лучше 4 сделать", и сделали другой на 4 месяца.
В общем, нет никакой проблемы в том, что у компании с несколькими сотнями разработчиков есть 160 графиков для разных показателей. 10 команд по 10 показателей на каждую, это уже 100 разных графиков.
Один раз назначить сквозной тэг команде, который она будет везде ставить в коммитах и тасках, а потом автоматически брать все проекты компании, фильтровать по тэгу и выводить в 1 дашборд на команду? Не, это слишком просто, пусть тимлиды вручную с дашбордами трахаются.
Какой еще тег, чем он отличается от ссылки на проект? Такое ощущение, что вы ищете лишь бы к чему придраться.
который она будет везде ставить в коммитах и тасках
Да, вместо того чтобы тимлид один раз в месяц задал нужные настройки в интерфейсе создания дашбордов, будем заставлять всю команду каждый день в каждом коммите и в каждой задаче вручную ставить какое-то специальное значение. Это не проще, а сложнее.
Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым issue можно и так прекрасно собрать.
А если нужна статистика по репозиториям, то в коммитах есть email автора. Берём его, находим в Джире его аккаунт - вот и понятно к какой команде он относится.
Сделать скрипт и запускать его ночью, чтобы он пробегал по всем репозиториям в компании, делал статистику по Джире и делал отчёты для менеджмента, как раз к их утренней чашке кофе, в разрезе по каждой команде разработки отдельно со сводным по всем командам.
и статистику из Джиры по закрытым issue можно и так прекрасно собрать
Ну так автор той статьи так и сделала.
Сделать скрипт, чтобы он делал статистику по Джире и делал отчёты для менеджмента
Ну так их Team meter и есть такой скрипт.
А зачем тогда загружать ручной работой программистов? Почему dashboard per project? Почему так и не сделали сводный отчёт для топ-менеджмента?
Откуда вы взяли информацию про загрузку ручной работой программистов? В той статье ничего подобного нет.
Почему dashboard per project?
Я так понимаю, потому что основная цель была отслеживать качество по отдельным проектам.
Откуда вы взяли информацию про загрузку ручной работой программистов? В той статье ничего подобного нет.
Я, честно, устал вам повторять: программисты вручную делают дашборды для каждого проекта, вместо того, чтобы либо сами менеджеры делали эти дашборды, т.к. они им нужны, а не тимлидам, либо все дашборды были автоматизированы. Но вы упорно отказываетесь видеть в этом ручной труд. Такое впечатление, что вам что-то не позволяет это сделать.
Я так понимаю, потому что основная цель была отслеживать качество по отдельным проектам.
Цель была - сделать инструмент для топ-менеджмента, позволяющий сравнить команды между собой. Кто перформит, а кто - нет. Отслеживание качества у них и так было. Об этом вы и сами писали, но уже, видимо, забыли.
Я, честно, устал вам повторять: программисты вручную делают дашборды для каждого проекта
Ну и я тогда вам повторю. Откуда вы взяли эту информацию, что каждый программист команды тратит какое-то статистически значимое время на создание этих дашбордов?
"Устал вам повторять X" не является ответом на вопрос "Откуда вы взяли эту информацию?". Ответом является какая-либо цитата из оригинальной статьи.
т.к. они им нужны, а не тимлидам
Это неверное утверждение, тимлидам статистика по багам тоже нужна, да и обычным программистам это тоже интересно. Ниже человек, работающий программистом в этом банке, это подтверждает.
либо все дашборды были автоматизированы
Судя по описанию, они и так автоматизированы насколько возможно. Задаете настройки, получаете график. Настройки вы в любом случае должны задать сами, так как машина мысли читать не умеет. Как минимум период, проект и т.д., которые вам нужны.
Цель была — сделать инструмент для топ-менеджмента, позволяющий сравнить команды между собой.
Не вижу, каким образом это противоречит утверждению "по отдельным проектам".
Почему dashboard per project?
Кстати, а откуда вы взяли информацию про "dashboard per project"? На скриншоте эта настройка называется "Выберите ключи проектов из списка" с пояснением "в которых команда ведет работу". То есть все так, как вы и хотите.
При этом может быть так, что команда помимо основного проекта делает какую-то внутреннюю библиотеку для программистов, количество багов в которой никого не интересует, и поэтому не надо чтобы они искажали основную статистику.
Отслеживание качества у них и так было.
У кого-то было, у кого-то не было, цель была сделать универсально во всей компании.
"При этом в каждой команде свои процессы и подходы к метрикам"
"мы насчитали шесть разных подходов"
"В этой статье я расскажу, как мы внедряли единые метрики"
Прочитайте уже ту статью внимательно, а то вы постоянно спорите с чем-то, чего там нет.
Олег, перелогиньтесь.
Ага, вместо того, чтобы признать свою неправоту, надо обвинить собеседника. Достойный взрослого человека поступок.
Вот уж действительно, стадный инстинкт.
Нет. У вас своя точка зрения, у меня своя. Мы пытались друг друга переубедить, но в итоге каждый остался при своём, потому что мой опыт говорит мне одно, а вам - другое.
Я вас ни в чём не обвинял: "%{username}, перелогиньтесь", - довольно старая шутка.
Вот я и говорю, ваша шутка неуместна.
потому что мой опыт говорит мне одно, а вам — другое.
Это не вопрос опыта, это вопрос того, что написано в исходной статье.
Ваш опыт говорит, что программисты "не тратят какое-то статистически значимое время на создание этих дашбордов", так?
Это не вопрос опыта, это вопрос того, что написано в исходной статье. В исходной статье этого не написано, и нет никакой косвенной информации, по которой это можно было бы предположить. Если вам кажется, что есть, вы могли бы привести конкретные цитаты и сказать "Из этого следует, что каждый программист каждый день тратит время на этот график, делая для него такие-то действия", но вы этого не сделали.
Если вам почему-то интересен именно мой опыт, то да, мой опыт говорит, что все усилия на создание такого графика это заполнить несколько полей в форме, это занимает несколько минут один раз в месяц, что не является статистически значимым временем, и делает это один тимлид, для которого повышение качества работы команды является одной из рабочих обязанностей.
Уважаемый автор, ваши эмоции более-менее ясны, но над текстом всё же надо поработать - ведь это не так-то и просто - понятно и доходчиво излагать свои мысли.
Наглядная демонстрация почему программисты вместо того что бы стать чем-то вроде масонов, держащих мир за глотку, все больше и больше становятся чем-то вроде сантехников, крутящих типовые гайки типовыми инструментами. Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
Выступил менеджер, поставил проблему, нарисовал пути решения, показал графики, расписал процесс. Ворвался программист, заорал что-то невразумительное, потряс каким то мистером Сиай Сиди, всех обосрал, ничего вразумительного не прибавил. Когда он свалил все культурные люди выдохнули, и продолжили обсуждать цвета графика для нового дашборда.
Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
Это некоторая иллюзия. Безусловно "незаменимых нет", но также безусловно "кадры решают всё".
См. Брукса — любая замена/добавление людей в команду замедляет разработку. Если этим заниматься чересчур активно, то замедление может быть просто фатальным — у любого проекта есть некоторое окно, в течение которого он должен быть завершён, иначе он перестаёт быть интересным и тихо гибнет в корпоративных катакомбах.
Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
раскройте, пожалуйста, этот тезис с аргументами.
я правильно понимаю, что программиста с высокой зарплатой можно заменить без потерь и сожалений на другого, менее опытного и с зарплатой ниже?
я правильно понимаю, что программиста с высокой зарплатой можно заменить
без потерь и сожалений на другого, менее опытного и с зарплатой ниже?
Конечно можно. Сожаления — это просто субъективная вещь, а потери, хоть они и объективны, могут быть либо неочевидными (сколько-то месяцев времени пониженной производительности команды — кто её так точно меряет?), либо вообще они могут быть потерями для конторы целиком, но не для лица, принимающего решение о замене.
Основная мысль ясна, но подача материала вызывает ещё больше вопросов к и без того не очень читаемому тексту и очень сильно ветвит обсуждение. Почитал комменты, - такое ощущение, что много людей поняли текст по-своему, поэтому складывается впечатление, что обсуждают вообще разные тексты :))
Я вот тут подумал ... а что если ... есть такой Хабр для менеджеров, где ругают программистов?
был. пару тройку лет назад... как там его.... чорд...
третий портал хабра, вместе с гиктаймсом был...
даже нагуглить щас не могу...
Вряд ли. А че их ругать? Им сказали, они делают. Обычно ругают тех, кто выше по статусу и непосредственно влияет на процессы.
Пользователи ругают программистов: криворукие
Программисты ругают менеджеров: сроки
Менеджеры ругают руководство: планы, задачи
Руководство ругает владельцев бизнеса: деньги жмут
Владельцы бизнеса ругают страну: налоги, штрафы, проверки, санкции
Страны гавкаются с другими странами.
- Designer 101-404 приступим. Готовы?
- Готов.
- Ваша контрольная фраза.
- Кроваво-черная заливка залила группу слоёв, связанных внутри, слоёв, связанных внутри, слоёв в едином макете и явственно, до жути на бекграунде тьмы ввысь белым бил логотип.
- Правки.
- Правки.
- Вам дают правки? Вносим.
- Вносим.
- Доводилось ли вам работать сутками? Вносим.
- Вносим.
- Когда вы не исполняете обязанности, вас держат без кофе? Вносим.
- Вносим.
- Одобрено.
- Одобрено.
- Что вы чувствуете держа в руках ТЗ? Одобрено.
- Одобрено.
- Вас просили играть со шрифтами? Одобрено.
- Одобрено.
- Вы жаждете вносить правки? Одобрено.
- Одобрено.
- Вам снится клиент? Одобрено.
- Одобрено.
- Вы и проджект менеджер. Связаны.
- Связаны.
- Вы чувствуете, что вам чего-то не хватает? Предоплаты.
- Предоплаты.
- Никакой предоплаты.
- Никакой предоплаты.
- Повторите три раза "Заказчик и сам так нарисует"
- Заказчик и сам так нарисует. Заказчик и сам так нарисует. Заказчик и сам так нарисует.
- На этом все. Designer 101-404 стабилен.
e-xecutive.ru ?
@nneeoo спасибо, что написали статью. Может изложение, как тут пишут, "от Олега" и эмоционально, но зато от души.
После вашей статьи я прочитал статью @irintus.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
В самом начале текста у Ирины есть целеполагание: топ-менеджмент захотел инструмент, чтобы "соотнести команды между собой", но в статье нет ответа зачем это понадобилось менеджменту =)
И если подвести итоги той статьи, то:
Дашборд для топ-менеджмента так и не был создан. Т.е. задача не была выполнена.
Программисты Тинькоф теперь должны не только писать код, доументировать, Jira и т.п., но и вести свой дашборд качества. Т.е. топ-менеджмент создал дополнительную нагрузку на программистов, хотя отчёты нужны менеджменту, и, как мне кажется, менеджмент и должен заниматься этими отчётами.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
Мне показалось, что причины обозначены в самом начале статьи, где команды "должны были обратить внимание на качество своей работки". Если менеджер так говорит, значит он будет снижать тебе ЗП. Proof me wrong, что называется.
Ну и конечно, итоги вы подвели абсолютно верно.
Извините, но у статьи стойкий запах Шизофрении. Не смог разобрать этот бред, нужен опытный психиатр или человек на той же волне
У статьи стойкий запах ужасного оформления. То, что она так сильно завязана на статью в шапке -- тоже можно отнести именно к оформлению.
Если Вам действительно нужно разобраться в этой статье, Вы прочитали оригинальную и проблема не исчезает, то стоит поработать над этим https://ru.wikipedia.org/wiki/Рабочая_память моментом.
Напомнило прекрасную метрику в одной из компаний где я работал: kpi = (число багов на проде) / (число человек в команде). Вывод - лучше всего метрика была у больших команд, которые ничерта не делают.
жаль, что некогда хороший банк, который мог помогать клиентам решать их вопросы (мне за один звонок увеличили ограничение на снятие наличных, так как надо было совершить крупную покупку за нал, а я стоял как дурак у банкомата и не мог снять более 150тр), теперь самовыпиливается вот таким бездарным образом, раньше мобильное приложение тинькофф было действительно помощником, а сейчас это просто корзина с багами, при том, что они умудрились поломать то, что прекрасно работало ранее
Ребята, ничего личного.....просто бизнес. Я давно ждала, как минимум - года три....когда же Банк Тинькофф перепродадут третьему лицо или его "под свое крыло" возьмет государство.
Все будет хорошо....зерно перемелется и будет мука....после будет и хлебушек....
И что же тогда произойдет?
Все под контроль государства. Банк будет выкуплен по итогу государством.
Хорошо, задам вопрос иначе. Что же тогда будет хорошо?
Ну если Вы думаете, что гос-банк - это плохо...Вы ошибаетесь....
Это гос-контроль и контроль отмыва и вывода денег за рубеж.
Вы наверное не в курсе - бардак был в 90е денежными потоками и коммерческими банками. Поэтому гос банку я больше доверяю . И средств и сил у них больше для автоматизации процессов и ведения бизнеса. А технологии всегда можно подсмотреть и кейсы по улучшению пользовательского интерфейса и всяких примочек.
А у кого вы собираетесь подсматривать технологии, когда все банки станут государственными? Между ними не будет конкуренции (потому что акционер-то у них один и тот же) поэтому искать как и чем улучшить сервис смысла нет.
контроль отмыва и вывода денег за рубеж.
Лютый бред. Во-первых, вывод денег за рубеж не является преступлением. Во-вторых, требования по контролю за отмыванием устанавливают ЦБ и Росфинмониторинг, и эти требования оданаково распространяются и на частные банки, и на государственные. Любой банк обязан их выполнять.
И кстати, в США тоже все крупные банки и фирмы - пож контролем государства и ЦРУ. Далеко ходить не надо. Цукербегра за жабры взяли еще 2 года назад..вроде как просто переименовали в Мета...да нет, взяли под полный контроль...как марионетку...И Илон Маск на ЦРУ и ВС США работает.....
Оригинальную статью, если что, не читал.
Но сложилось ощущение, будто автор выучил наизусть четыре буквы, и решили их применять везде к месту и не к месту.
Либо автор никогда не работал в enterprise и занимается исключительно разработкой небольших библиотек в Opensource.
Ну и по классике: Как не надо мы узнали, а как надо?
===
«Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?»
Да, это называется CI/CD
Нет, это называется не CI/CD
===
Доказательства отсутствия проблем через тестирование больше недостаточно. Даешь SLA! Что такое SLA? Это KPI. Не достал до KPI – не поел.
Через автотесты можно проверить, что нет багов (и то только при условии, что баг не появился на этапе анализа)
Через автотесты можно проверить обратную совместимость.
Через хитрый ci/cd с канареечным деплоем можно протестировать на проде на реальных пользователях.
Через тестирование невозможно проверить, как твоя команда поддержки реагирует на разные внештатные ситуации, где автоматика не справляется.
Через автотесты невозможно проверить, что при анализе действительно были учтены все варианты.
===
Новичок задает вопросы? Так делать нельзя, график вверх – плохо. Разработчики, новенькие и техническая поддержка не должны общаться напрямую, это поднимает линию вверх, а вверх это плохо.
Это очень эффективная мера по подавлению инициативы, у компании не будет будущего, если новички не будут вовлечены в процесс.
Для задавания вопросов есть чат и команда. Не стоит на это service desk приплетать.
Да и тот же service desk может просто закрыть запрос по причине "не ошибка" и всё.
===
«Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.»
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
Как раз наоборот.
Если фичу отправили в тест - там чисто по статистике не должно быть "много дефектов", тк при нормальных процессах - большинство дефектов должны быть закрыты ещё на этапе анализа и написания автотестов.
Если у тебя куча дефектов на тесте - значит разраб пишет по принципу "хуяк хуяк и продакшен", а анализа нет в принципе, как и обратной связи разработчик-заказчик.
===
...
С этой же ситуацией сталкиваются все «агиле коучи», команда тестирования не пропускает релиз потому, что получит по башке из-за «дефектов на проде», а команда разработки больше не может деплоить в прод, потому что команда тестирования не пропускает релиз.
Если такая ситуация произошла - значит процессы кривые.
В этом случае есть ряд вопросов:
Почему разработчики так торопятся и хотят пушить в прод без тестирования?
Почему QA не пускает без тестирования?
Если это очень горячий фикс в одну строку, то откуда разработчики узнали, что там действительно нет новых дефектов, или что этот фикс реально нужен?
Если это не хотфикс, а фича, то почему они хотят пропустить тестирование?
Если это очень горит и заказчик берёт ответственность на себя, то почему бы и не запушить?
В процессе явно нужен способ, как ответить на все эти вопросы - тогда и менеджер будет доволен, тк имеет адекватные метрики, которые реально говорят о проблемах, и команда будет спокойна.
===
...
А зачем нам джира, когда есть VCS? Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
А точно ли может?) Может к opensource и разработке библиотек это и правда применимо, но как это применить ко всему остальному - без понятия.
Хотел бы ваше мнение узнать.
===
...
Если есть рабочий CI/CD пайплайн, почему бы не взять его за основную метрику?
Потому что CI/CD это только про автотесты и деплой, но не про рантайм?
Если бы CI/CD мог ответить на все вопросы, то Grafana и логи были бы просто не нужны, как и поддержка.
Зачем нам принимать запросы от пользователей, если у нас пайплайн зелёный ну?
Как-то раз после одной операции доктор на длительное время запретил мне все виды физических нагрузок, в том числе "половую жизнь" ©, но даже по истечении этого срока у меня не было ТАКОГО передергивания, как в посте.
Складывается ощущение, что автор вырос как специалист в какой-то одной компании с очень специфическими процессами (которые для самой компании могли быть оптимальными с учетом специфики), принял это кривое зеркало за стандарт разработки и через такую вот призму смещенного восприятия прочитал комментируемый материал.
Глянул исходную статью, всё там сделано довольно грамотно, если не забывать, что разработка нужна не для разработки ("не мешайте мне кодить!"), а чтобы приносить деньги своему работодателю.
Взять к примеру две команды: одна занята проверкой гипотез в каком-нибудь второстепенном продукте, как следствие имеет низкую «стоимость» бага на проде, но зато требует быстрого деплоя. И вторая команда, которая пилит финансовую платформу, имеет 10 кругов тестирования и деплои раз в полгода т.к. стоимость бага очень высока. У этих команд процесс разработки и деплоя будет разный, воркфлоу в джире разный, пайплайны разные, и даже отношение к критериям «баговости» разное. Как можно сравнивать качество работы этих команд, по графикам багов в джире?
А какая-то из команд может быть вообще эксплуатирует сторонний софт и для них баг в джире — это отражение процесса общения с вендором по поводу фикса стороннего софта.
Это похоже на сравнение качества работы команд сборки урожая по соотношению мятых плодов. Сборщики изюма вечно страдают, зато сборщики кокосов счастливы.
Это старая игра — на каждый подход можно придумать с десяток исключений.
Насколько я понял, эти метрики используются не только для сравнения команд, но и для отслеживания их динамики.
Но, может быть, вы знаете, как QA-хэду более лучше следить за качеством всей разработки?
Без единого подхода к метрикам соотнести команды между собой очень сложно. Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
В планах — построение еще одного дашборда качества для руководителей, с помощью которого будет возможно быстро проанализировать и сравнить несколько команд в рамках одного департамента.
Можно сравнивать, но не только по одной метрике и по результату сравнения не выносить какие-то приговоры, а принимать решение присмотреться к тому, что происходит в команде.
Если есть аномалия - исследовать причины. В первом случае, например уяснить разницу между командами. Во втором попросить помечать внешние баги особым образом. Заодно будет видно насколько этот внешний софт забагован.
Я прочитал ваши комментарии к той статье. Цитирую:
Прям есть:) Более того за ними никто не ходит и не заставляет этими бордами пользоваться, есть такие метрики только по одному из типов дашбордов качества:- уникальны пользователей: 147- просмотров 743Кажется неплохой результат, учитывая, что вряд ли туда заходят по одному, скорее всего эти борды открывают вместе с командой раз в какой-то период для ретроспективы или планирования. Также есть метрика по количеству новых дашбордов, в среднем это 10 дашбордов в месяц от пользователей, которые узнали о продукте из каких-либо внутренних источников.
Уважаемый, зря не вникали. Потому что никакой анкеты то нет. И на дашборде нет никаких индивидуальных метрик по людям, только командные. В "анкете" собирается информация о том, как люди ведут проекты в Jira, никому не интересно "Где, кто, с кем, сколько раз.".
Вы работаете в тинькове? Можете представить минимальное, не деанонимизирующее вас доказательство этому?
Если да, то я бы хотел задать пару вопросов, если вы не против.
Давайте попробуем в качестве доказательства фотографию с монитора, где видно фрагмент кода любого сетевого IO. Можете отправить сюда или в личку, как вам комфортнее.
И сразу вопрос. Что конкретно имела в виду irintus, когда вводила SLA? Что имелось в виду под SLA и какие действия от вас это SLA требует?
Может быть Service Level Agreement — соглашение об уровне сервиса, где может быть указано и время необходимое для решения задач?
Соглашение вырабатываемое на основе исследований системы где выявляется возможности и определяются значение не свойственные этой системе, а дальше вырабатывается SLA — которое является опорой для возможных улучшений системы.
Когда говорят о системе, говорят о сервисе построенного для решения каких-то задач.
Вероятно, в тинькове используется чуть иное понятие SLA. Можете пояснить подробнее, где-то в документах критерии SLA зафиксированы? Обозначена ответственность и какая-то система учета по этой SLA? И чем он отличается от KPI?
Примеры из других команд тоже подойдут.
Опуская вики и внутреннюю документацию, которая, я подозреваю, уже была. Смотря на вещи в перспективе, как описанная irintus система помогла вам получить софт лучшего качества?
У вас есть пример успешного применения?
Практика разбора дефектов была у многих команд, но носила стихийный характер. Есть проблема — разбираем, нет проблемы — значит, все хорошо. Так мы поняли, что статистику дефектов, ее анализ, постановку целей по улучшению и SLA мало кто делал
Тут имеется ввиду, что команды сами себе SLA не делали? В чем смысл команде самой себе SLA выдумывать? Между кем и кем будет это соглашение, если второй стороны нет?
Мама, я в телевизоре!
Отличная статья! Автор, а вы читали https://habr.com/ru/post/672012/?
Свойство систем приходить к стабильному состоянию. В данном случае это "кто-то, что-то как-то и зачем-то делает ну и получается какой-то результат".
Кто-то, что-то, как-то, зачем-то - не обязательно неизвестные величины, какой-то - не обязательно плохой результат. Но вот дестабилизировать систему может быть весьма просто. Можно приравнять какой-то в результате к плохому с целью наказать, не влезать в кто, что, как. Можно оптимизировать один или несколько, также не влезая.
Притча
Однажды компания позвала мудреца сделать лучше. Мудрец сказал - заплатите мне пока за разговор со всеми, а дальше будет видно. 3 дня и 3 вечера общался мудрец. Вернулся @Zibsunи сказал - у вас все конечно странно, но оно работает, а если менять может стать хуже.
Наглядная иллюстрация конфликта разработки и топ менеджмента, когда люди вместо того чтобы договариваться и решать общие проблемы всячески мешают жить друг другу. Результат в заголовке (или нет, просто все недовольные ушли).
Правых тут, очевидно, нет. Кто виноват — сложно судить, чаще всего так бывает из-за отсутствия компетентного технического топ-менеджмента (CTO, VP of engineering etc), способного разрешить этот конфликт.
Хорошим менеджером быть несложно — ставишь любое КПИ и за пару-тройку лет рефакторишь его до вменяемого. Подумаешь, по людям проехался — неудачники нам не нужны! /ваша сова
Какой банк, такая и разработка
Убийство разработки – опыт Тиньков Страхование