Вечером зашел на Хабр, отсортировал статьи по лучшим за сутки, вверху списка наткнулся на статью «Как убить разработку в три шага и на четвертый навсегда похоронить».
Хтонический ужас нависал над хабром, не заминусованный. Я судорожно вышел из ридонли. Мне хочется кричать, но я бью по клавишам, пишу, что рвется наружу, на этот лист.
Автор статьи – irintus (имя изменено), в подробностях рассказала зачем и как она убила процесс разработки, куда и какие зонды вставила, но забыла написать, чего этим добивалась. Давайте я это исправлю.
Почему единые метрики качества — это важно для денег
Если на вопрос поставленный так:
Без единого подхода к метрикам соотнести команды между собой очень сложно
У вас же есть CI/CD, значит и метрики есть.
Вы отвечаете так:
Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
Не завидую вам, ребята
То вы - манагер. А если вы манагер, значит, софт вас не интересует, вас интересуют отчеты. Только зачем нужны отчеты?
В дальнейшем по тексту мне начало казаться, что работников будут финансово стимулировать. А отрицательное финансовое стимулирование, как известно, тоже стимулирование.
Доктор Джордан Питерсон однажды обозначил различие между злом и трагедией. Ото зла трагедию отличает факт того, что она случается сама. Мы не можем обвинять град в том, что он побил нам помидоры. Побитые градом помидоры это - трагедия, а вот если ваши помидоры побил сосед, то это уже зло.
Но как будут собираться метрики?
Шаг 1: находим все, что дорого
Как и любой другой манагер, Irintus первым делом начала смотреть на то, что уже работает. Ведь зачем приходить в компанию с набором готовых, рабочих практик, когда можно уничтожить существующие?
Чтобы не изобретать велосипед, мы решили начать с исследования того, что уже сейчас есть в командах. Наши первые вопросы были такие: «Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?»
Да, это называется CI/CD
Практика разбора дефектов была у многих команд, но носила стихийный характер. Есть проблема — разбираем, нет проблемы — значит, все хорошо. Так мы поняли, что статистику дефектов, ее анализ, постановку целей по улучшению и SLA мало кто делал.
CI/CD и тестирование на продакшене это стихийный процесс. Стопроцентное покрытие кода – стихийный процесс. Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.
Доказательства отсутствия проблем через тестирование больше недостаточно. Даешь SLA! Что такое SLA? Это KPI. Не достал до KPI – не поел.
Потом мы проанализировали ответы на вопрос: «Как вы отличаете дефекты теста от дефектов прода?» — и обнаружили первую проблему.
* Дефекты прода — дефекты, найденные на прод-среде после завершения тестирования и выката на продакшен.
* Дефекты теста — дефекты, найденные на любой из тестовых сред
Юнит тесты, интеграционные тесты и тесты на продакшене, все слиплось… пелена на глазах… трудно дышать…
Устраивать Jira-фашизм и заставлять всю компанию перейти к одному-единственному подходу нам не хотелось. Поэтому стали копать дальше. Более глубокий анализ показал, что из всех подходов есть абсолютное большинство, и мы смогли выделить четыре варианта разделения дефектов теста и прода.
Удобство, интеграция с IDE, CI/CD. Незнакомо… непонятно... Сжечь, уничтожить, заменить.
Шаг 2: искажаем, заменяем, уничтожаем
Irintus, манагеры, пожар, ураган или наводнение, это феномены, в них нет ни жалости, ни корысти. Не нужно винить огонь в том, что он поглощает топливо, их приход - трагедия. Но коптящий огонь инквизиции заговорил. И рассказал, что сделал, как уничтожил, подробно, цинично, по пунктам. Вот вам, краткий дайджест:
1. Заставить молчать
Пт. Количество заведенных и закрытых дефектов & пт. Соотношение дефектов и задач
«График закрытых дефектов должен быть приближен к графику заведенных. Обратное говорит о том, что команда не успевает исправлять все заведенные дефекты.»
Гит заменяется на джиру, больше нельзя заводить TODO, и обсуждения, нельзя писать RFC, иначе графики не совпадут. Теперь только баг репорты.
Конечно, чтобы подстроиться под KPI, люди кое-чо придумают, но пусть Irintus узнает об этом сама.
2. Запретить вопросы
Пт. Количество отмененных дефектов по месяцам для теста и прода
«график показывает, сколько дефектов заводится впустую, то есть неэффективно потраченное время команды.»
Новичок задает вопросы? Так делать нельзя, график вверх – плохо. Разработчики, новенькие и техническая поддержка не должны общаться напрямую, это поднимает линию вверх, а вверх это плохо.
Это очень эффективная мера по подавлению инициативы, у компании не будет будущего, если новички не будут вовлечены в процесс.
3. Запретить тестирование
Пт. Состав релизов
«Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.»
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
Если нам необходимо подавить активную разработку, то почему бы и нет, инициатива хорошая.
4. Запретить релизы
Пт. Коэффициент ошибок, пропущенных на прод
«показывает качество тестирования, проработки требований и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на прод.»
Напоминает на внедрение плохих врачебных практик в США. Лечение там опирается на строгие критерии от FDA.
Бывает, врач знает, что вот это лекарство, если дать его прямо сейчас, спасет человеку жизнь, но врач пациенту его не даст, потому что он нарушит гайдлайны FDA.
«Пойду домой, приму решение, может быть риск того и стоит, утро вечера мудренее». Подумал доктор. На следующий день пациент умер, проблема решена, совесть чиста, виновен FDA, Rinse and repeat.
С этой же ситуацией сталкиваются все «агиле коучи», команда тестирования не пропускает релиз потому, что получит по башке из-за «дефектов на проде», а команда разработки больше не может деплоить в прод, потому что команда тестирования не пропускает релиз.
Это закономерно породит цикл обвинений как на знаменитой диаграмме «заказчик-вендор-интегратор», а также разорвет фидбек с клиентами. Отличный результат!
5. Разрушить пайплайн
Пт. Распределение дефектов по приоритетам для теста и прода
«показывает, как соотносятся между собой количество дефектов с разными приоритетами для прода и тестовых сред.»
Вся сила CI/CD в том, что, работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно. Все постоянно фетчат все изменения и всегда в курсе последних изменений, это удобно.
Сделал тесты, написал код. Проверил, все ли работает, прогнал тесты – запушил.
На сервере сборки началось тестирование – все хорошо, все прошло, все тесты зеленые -можно в релиз.
Это очень мощный инструмент, ускоряющий разработку и облегчающий жизнь всем.
Однако, если мы хотим это разрушить, то давайте заведем в джире отдельный стак ишшуев для дев и для прод. Отличная идея!
Такой подход неявно предполагает, что прод и дев это два разных пайпа или бранча, которые отдельно поддерживаются. Двойной оверхед при разработке.
Шаг 3: активные меры по подавлению разработки
Оставлять разработчиков наедине нельзя, иначе все обретет рациональные формы и станут звучать рациональные вопросы.
- А зачем нам джира, когда есть VCS? Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
- Если есть рабочий CI/CD пайплайн, почему бы не взять его за основную метрику?
Чтобы подавить это, нужна активная бюрократия и красивый дашборд, в котором бюрократы смогут рассматривать цветные графики и пытаться их анализировать., проводить митапы и консультировать всех по поводу того, что они придумали.
Шаг 4: похороны
Похороны процесса разработки сопровождались такими церемониями как «встречи-презентации» и «получение консультаций». В тинькове они, кстати, обрели ритуалистический характер. Успение разработки теперь отмечается у них постоянно.
В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.
Такой процесс я называю «End to end похороны», когда ни работники, ни начальство не понимает, зачем нужны метрики и чем одна от другой отличается.
Саботаж?
В своем обзоре я выделил только интересные участки. В целом, тут пробы негде ставить почитайте сами. Задачи, которые были достигнуты, походу, были поставлены так:
Установление токсичной атмосферы, где сотрудники компании будут ожидать «ножа в джиру»
Как можно чаще вытаскивать людей из интегрированных сред для разработки
Заставить умалчивать проблемы
Отбить новичкам желание задавать вопросы
Задерживать новые релизы
Поощрять code bloat, заставить писать mockery вместо тестов
Демонтировать CI/CD пайплайн
Уменьшить социализацию внутри команды
Но это еще не все, у них в планах:
1. «Построение еще одного дашборда качества для руководителей, с помощью которого будет возможно быстро проанализировать и сравнить несколько команд в рамках одного департамента.»
Т.е. Посеять раздор и нездоровую конкуренцию между командами
2. «Прислушиваемся к хотелкам команд и развиваем текущие дашборды: делаем новые графики, улучшаем визуализацию ранее созданных графиков, добавляем фильтры и новые возможности для удобства использования.»
Т.е. поощрять итальянские забастовки и подрывную деятельность между командами
Заключение | Imprisonment
Учитывая весь контекст и основываясь на данных из статьи и новостных источников, делаю вывод – это саботаж и попытка устранения конкурента с помощью найма вот таких кадров.
Вдогонку лишь скажу, что как же хорошо, irintus, что я работаю не с вами.
Вперед, сначала банк, потом страхование. Так победите!
Комментарии (154)
dopusteam
27.08.2022 17:32+56
Если на вопрос, то вы - манагер.
Что то я в самом начале застрял, можно пояснительную бригаду?
DrinkFromTheCup
27.08.2022 20:52+39Цитирую абзац, из которого взята фраза на скрин-шоте:
Без единого подхода к метрикам соотнести команды между собой очень сложно. Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
Беда в том, что цитируемый менеджер не допускает даже мысли о том, что единой метрики для разных команд нет и быть не может.
У кого-то продукт менее дефектоопасный, у кого-то сезон более простых проектов, а кто-то и вовсе формально работает компании в убыток, прибирая за другими командами или открыв сезон охоты на легаси... да мало ли причин!
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.NB: я ни разу не автор - но я осмелюсь предположить, что автор имеет в виду что-то такое. Сам сталкивался и вроде бы что-то в этом понимаю... но мало...
xeeaax
28.08.2022 22:42+2А откуда взялось утверждение, что менеджмент по этим метрикам собирался сравнивать несравнимые команды? Есть какой-то список команд хотя-бы, чтобы делать выводы об невозможности их сравнить? Или менеджмент априори дураки и будут одни и те же требования предъявлять к машинам для перевозки пассажиров и сжиженного газа?
DrinkFromTheCup
28.08.2022 23:36+6Утверждение - взялось из опыта. Даже если со стороны кажется, что две команды полностью идентичны как по скиллам, так и по характеру реализуемого продукта, - серьёзные отличия имеются. Основные причины я начерновую перечислил. Добавим наверх различия в манере управления и различное отношение к различным элементам рабочего процесса - и начинается пресловутый выпас котов...
Списка команд (и прочих околичностей) не нужно. Размазывание степени и характера нагрузки - это очень здравая тактика. То есть в сколь-либо крупной фирме поймать момент, когда все занимаются схожими задачами со схожей... как это назвать по-научному - хз... счислимостью, что ли, - малореально. Это тупо не выгодно ни бизнесу, не терпящему просадок, ни разработке, жаждущей разнообразия задач. Да и тот же SCRUM каждая команда понимает несколько по-своему. Это ж не Десять Заповедей, разные части ритуалов выполняются не везде и неодинаково.
Не то чтобы менеджеры априори дураки. Просто считать, что "для того, чтобы управлять чем-то, надо в этом досконально разбираться" перестало быть принято.
В тех редких случаях же, когда руководство осознаёт наличие потребности "управлять, понимая", - кадры, одинаково хорошо смекающие И в кодинге, И в менеджменте, привлекаются в первую очередь на техлидские, архитектуростроительные, etc-etc позиции. Причём, с меньшим головняком и на куда бóльшие деньги.
А на [якобы чисто] менеджерские позиции приходится набирать деятельных юнцов и юниц, вызубривших всякой фигни на пару сертификатов и убедительно умеющих пускать пыль в глаза. И надеяться, что, во-первых, вольются в общий флоу компании, а во-вторых, наберутся уму-разуму по технической части. И станет хорошо.
Беда в том, что хорошо треплющийся юнец со стопкой сертификатов не умеет вливаться да ума набираться. Он УЖе уверен в том, что раз у него сертификат в зубах и должность под ххх, - весь мир у него в кармане и все должны под него гнуться. По должностным инструкциям обязаны. Спеца на договоре то так просто не уволить, а косяки менеджмента доказываются тяжко и кошмарно...
И начинаются трения со столкновениями, до искр и хлопаний дверьми.
Я отдаю себе отчёт, что я даже не юнец с сертификатом, поэтому панически боюсь и избегаю таких позиций. А если неминуемо засасывает куда-то рядом - в меру своих куриных мозгов пытаюсь как-то вычленить и реализовать наименее отвратительный вариант развития событий. Не навредить.
Но %!., видимо, хреново стараюсь. Старался...
vkni
29.08.2022 15:22+3В кровавом энтерпрайзе законы Мёрфи таки действительно работают. :-(
DrinkFromTheCup
30.08.2022 14:54Лучше пусть будет иллюстрацией законов Мёрфи, чем Дилберта, чесслово.
nneeoo Автор
28.08.2022 01:25+20Спасибо, опечатку исправил.
Возьмем микросервисную архитектуру в тинькове за факт.
Часть команд будет заниматься одними сервисами, часть другими, где каждый сервис прикреплен к конкретной команде.
А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Сравнивать команды вне их предметных областей нельзя, но по тексту статьи, которую я прочёл, похоже, предлагается делать именно так.
Я думаю, что начальство взяло себе рычажок, которым будет рисовать надбавки и убавки, аргументируя тем, что тима фронтенда рисует 5 кнопок в день, а вы даже новую версию безопасной авторизации раз в пол года выкатить не можете.
TimsTims
28.08.2022 02:44+7Спасибо, опечатку исправил.
На хабре можно куски текста вставлять через цитирование: <blockquоte>цитата </blockquоte>
Очень трудно читать скриншоты с лишними, и просто криво подчеркнутыми словами. У вас где-то вставлены скриншоты как цитаты, а где-то наклонный текст, типа цитата. Каждый абзац разного формата. То скриншоты из Iphone на весь экран, то буквы мелким шрифтом, читать очень тяжело вашу статью.
Понял, что у вас горит на какого-то PO в тинькове страховании, но я думаю, что есть и нормальные команды, куда эта дама не добралась. Скажем так, я видел во многих крупных компаниях — как хорошие команды, так и токсичные. И это не значит, что вся компания токсичная.nneeoo Автор
28.08.2022 03:10+5Спасибо за подсказку, кривые скриншоты заменил на цитаты.
Хочу за одно оговориться, что я не качу бочку на разработчиков, я качу бочку на магагеров.
Статья, которую опубликовала irintus похожа на свидетельство падение цивилизации.
Я читал и мне казалось, что её написали варвары, освоившие письменность. Они заняли места, ранее занимаемые гражданами более развитой цивилизации.
Эти варвары пишут тем же языком, но ни по содержанию, ни по форме они не напоминают ранее существующую, которую с гордостью уничтожили, упростили.
Я знаю, что труд, который опубликован даже на заборе, резонирует, и может обратить распространение вот этой вот опухоли.
Прочитав статью, выдержат ли разрабы тинькова бахвальство, с которым irintus написала свой доклад?
Aleksandr-JS-Developer
28.08.2022 12:00А теперь давайте думать, как мы будем сравнивать команды, где одна из них занимается авторизацией и фродом, и команду, которая занимается бэкапами и аналитикой.
Ну, по количеству закрытых задач. Некоторые особенно эффективные менеджеры меряют количество написанного кода. Но это еще на уровень выше, чем у irintus.
anticyclope
27.08.2022 17:34+28Похоже на сообщение, которое должно было попасть в личку, но зачем-то оказалось на Хабре
nikolas78
27.08.2022 19:54+25Не, в личку жалко такой труд выбрасывать. На прекрасное итальянское — да, самое оно (там правда матов много, мне трудно читать), но это же конкурент Хабру, а значит на Хабр. Ну и разбор интересный.
dopusteam
27.08.2022 17:38+25CI/CD и тестирование на продакшене это стихийный процесс. Стопроцентное покрытие кода – стихийный процесс. Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.
А кто автор всей фразы то? Я что то такого не вижу
«Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?»
Да, это называется CI/CDЧто?
Norgorn
27.08.2022 21:33+28Я думал, что один далеко не всё понял.
Так-то боль автора понятна, часть претензий тоже. Но он настолько активно строил соломенное чучело, что необоснованных утверждений и откровенного передёргивания получилось не меньше, чем объективных моментов.
nneeoo Автор
28.08.2022 01:46+2Можно смело говорить, что в тинькове была серия автоматических тестов, возможно, даже был развернут дженкинс или тимсити с кучей серьезных тестов, которые должны проваливаться и должны проходить, каждый раз, когда софт идет в бой.
Манагер назвал конвейерное производство стихийным процессом.
Вот товарищ DrinkFromTheCup, в своем комментарии выше отлично просуммировал мои малосвязанные мысли.
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
dopusteam
28.08.2022 06:30+5Манагер назвал конвейерное производство стихийным процессом
А есть цитата конкретная? Я вот нашёл только
Практика разбора дефектов была у многих команд, но носила стихийный характер
И какая связь между CI/CD и сбором статистики по дефектам в проде?
nneeoo Автор
28.08.2022 08:09+1Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
А связь прямая - Testing in production и Observabilty это продолжение Continious Delivery. CD не заканчивается после успешного билда а CI не кончается после успешного развертывания на прод.
Прошу не путать подходы с DevOps, потому что DevOps это неправильный подход к CI/CD. Это отдельный холивар, который я бы хотел опустить.
dopusteam
28.08.2022 08:13+4Вы специально вопрос игнорите? Приведите цитату, где автор назвала "конвейерное производство стихийным процессом"? Без домыслов только, что можно рандомно менять "разбор дефектов" на "CI/CD"
Вы хотите опустить холивар, но ставите равенство между CI/CD и поиском дефектов на проде?
nneeoo Автор
28.08.2022 08:17В моем материале много домыслов. Включая этот пункт тоже.
Это чистый домысел, выведенный из контекста.
michael_v89
28.08.2022 10:12+5Я предполагаю, что инжинеры тинькова делали всё на высшем уровне, и не нуждались в "сборе дефектов".
В исходной статье речь идет о багах на проде. То есть вы считаете, что у них никогда не было багов на проде? На чем основано такое нелогичное предположение? Они даже у Гугла есть.
DarkTiger
27.08.2022 17:41+7Хтонический ужас провисел почти сутки, не заминусованный
"А мужики-то не знают!" (с)
atamaan
27.08.2022 17:57+61Понимаю боль автора от эффффффективных менеджеров... но текст вырви глаз...
xeeaax
27.08.2022 18:15+7Исходная статья https://habr.com/ru/company/tinkoff/blog/684608/ и перечисленные в ней подходы вполне адекватны, чего не могу сказать об этой статье. CI/CD не является панацеей при тестировании. И конечно никто CI/CD сжигать не предлагал в оригинальной статье, там даже слова такого нет.
nin-jin
27.08.2022 20:36+6Я так и не понял кто такой этот сисиди, который собирает статистику дефектов с прода. Интуиция подсказывает, что это следующая ступень развития девопса после деврела. Но есть сомнение..
BoberMod
27.08.2022 20:31+11Мне кажется, автор во многих местах, где упоминается "CI/CD", имеет ввиду монитринг и трекер ошибок, типа Sentry/Rollbar/New Relic. Тогда это имеет смысл.
CI, как метрику, можно использоваться разве что для отслеживания "производительности" тестов (аля "запуск тестов занимает много времени, давайте оптимизируем").
DrinkFromTheCup
27.08.2022 20:39+18Конечно, чтобы подстроиться под KPI, люди кое-чо придумают, но пусть Irintus узнает об этом сама.
Ухахахахааааааааа, дааааа, это будет весёлый сюрприз, плохо диагностируемый и ещё хуже наказуемый. Я прям чую знакомый аромат!
Ведь у него будет прям юридически выверенное обоснование - и "пересесть" с него обратно будет из-за этого очень, очень затруднительно...Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
По-хорошему, эта метрика - "погода на Марсе", у которой могут быть наиудивительнейшие причины.
Неожиданное "покраснение" этой метрики - это повод для постмортема (человеческого, с полноценным разбором, откуда "наросло" и как впредь "предотвратить"), а не для битья линейкой по рукам кого попало.
Но и не повод для гордости.
(и неожиданное "позеленение" - ТОЖЕ повод для разбора!)Статья дельная.
Увы, как я уже многократно ныл ранее, поскольку IT нынче перестал быть уделом серьёзных дядек с высшим образованием и стал рассадником нигилистов, который посоперничает по градусу деградации с произвольным форумом игроков в DOTA 2, - более адекватный подход УЖЕ НЕВОЗМОЖНО РЕАЛИЗОВАТЬ.
И даже потеоретизировать о нём.
Потому, что вездесущие и очень голосистые продавцы вагинальных чаш (откуда, чёрт возьми, они тут...) да утратившие здравый смысл и опыт человеческого общения любители побравировать репутацией очень быстро набегут и попытаются отнять Ваше время впустую.Берегите себя. Не ведитесь. N.G.U.N.S.
0x131315
30.08.2022 06:20+1Ох уж эти дедовские методы, до сих пор встречающиеся на местах. Тоже достало.
Битье линейкой вообще штука контрпродуктивная. Да, чисто по человечески хочется иной раз "наказать мерзавцев", но это именно что эмоции, пользы от них никакой, зато вред огромный, поэтому профессионалы держат себя в руках.
Это просто два разных подхода: конкурентный и командный. Многим разница не особо очевидна, но ее нужно понимать, и отдавать себе отчет, какого подхода следует придерживаться, и почему.
В первом важнее индивидуальный результат. Его можно усилить за счет упорного труда - тяжелый, сложный, для многих нереальный вариант: настоящих профессионалов всегда мало. Но можно усилить и за счет группы: разрывая коммуникации в группе, разрушая любые эффективные связки, педантично ослабляя конкурентов любыми доступными методами, чтобы на их фоне выделялся даже посредственный результат.
Во втором важнее групповой результат. Его также можно усилить за счет упорного труда: единицы профессионалов тащат основную нагрузку. И также можно усилить за счет группы: выстраивая более эффективные коммуникации в группе, усиливая координацию, создавая эффективные связки внутри группы, выявляя и удаляя деструктивные звенья.
MixaSg
30.08.2022 13:14И если мне нужен в контору слон, я лучше найму пятьдесят ворон. Десять сразу вон, остальным закон: «Работает только команда!»
Areso
27.08.2022 21:00+10Мне и моим многим знакомым приложение банка Т спамит пушами с мольбами о том, что им срочно нужны айтишники.
Впрочем, в банках везде ужас, но я надеялся, что хоть в Т он не такой.
numb
27.08.2022 22:45+1Я видимо удалил все их приложения, до этих пушей. Хотя их реклама, тоже напрягала.
ads83
27.08.2022 21:15-19Из общего тона статьи у меня создалось ощущение, что вы негативно настроены (либо к автору предыдущей статьи, либо к разработке в Тинькове, либо к организации). Но почему — непонятно.
Не могли бы вы уточнить:
- вас не устраивают описанные в предыдущей статье новвоведения (а до этого все было норм), качество отдельного продукта компании, вообще все продукты или что-то другое?
- Какое отношение вы имеете к Тинькову: участвуете в разработке, пользуетесь их продуктами или что-то еще?
Polniy
27.08.2022 21:30+98Я прочитал статью и ничего не понял. Как будто статью написал Олег.
Diamon33
28.08.2022 09:19Это как будто стенограмма (несуществующего) видео "Моя реакция на "Сказ про то, как мы метрики качества внедряли".
WondeRu
27.08.2022 22:50+3работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно
Это же сарказм? Не, ну, правда же? А?
DrinkFromTheCup
28.08.2022 00:57+9А почему бы и нет?
На одном из моих прошлых мест работы и вовсе просто титанических объёмов проект существовал как единый мастер-репозиторий.
В который, если я правильно помню, после минимальных смоук-тестов заливались фичи, с последующими регулярными проверками мастера на регресс.
И из которого же потом выделялись ветки очередных релизов.
И ничего, никто не умер.Правда, это требует совершенно нетипичной коммитной дисциплины.
Зато, вот честное комсомольское, рыться в их коде было сплошным удовольствием даже для меня, гуманитария до костей мозга.
Намного приятнее, чем при несколько более традиционном подходе "накоммитить в N веток, а потом итеративно эти ветки "женить". Потому, что коснись что - в карте коммитов и веток, больше напоминающей схему московского метро, а не репозиторий, концов не найти.И шлак в релиз в том мега-проекте попадал скорее из-за пренебрежения здравым смыслом в иных процессах.
0xd34df00d
28.08.2022 07:30+4А как вы ревью делаете?
Я такое себе позволяю только в личных проектах.
DragonFire
28.08.2022 09:16+1страшные ченжи - ревью в отдельной ветке, черри-пик в мастер.
не страшные - коммит в мастер, ревью и фиксы ревью тоже в мастер
DrinkFromTheCup
28.08.2022 10:41+1Смотря что считать "страшными" чейнджами, к слову. По моим наблюдениям, при таком подходе "страшным" может быть только рефакторинг какой-то сложной (и объёмной) логики, которую и залить по частям нельзя (не пройдёт смоуки), и не заливать по частям нельзя (тупо слишком много рефачить за один заход).
Коммитная дисциплина здорово облегчает жизнь и уменьшает градус "страха" потому, что даже в едином репозитории видно не только ЧТО изменилось, но и ЗАЧЕМ.
Если бы ещё "наверху" не воровали мою документацию на старый код, а писали свою, - можно было бы и на ходу отделять фичи от незапланированных перекосов логики и прочих ужасов.DragonFire
28.08.2022 15:14Если действительно нужно слишком много всего без мержа в транк делать то никто не мешает сделать ветку. Практика показывает что из 1к разработчиков это нужно двум одновременно:) все остальные прекрасно живут на мастере
rrrad
28.08.2022 22:26Работа в мастере (без хотя-бы минимального ревью) противопоказана в случае если в команде есть хотя-бы один человек, не разбирающийся по-нормальному, в работе гита (не важно - через консольные команды или через любимую gui-утилиту).
DragonFire
28.08.2022 22:46Права на пуш в мастер должны быть только у небольшой группы девелоперов. Все остальные запускают робота который проверяет компиляцию, тесты и сам мержит если все проверки выполнены.
В такой ситуации достаточно уметь делать pull и commit :)
rrrad
28.08.2022 23:42Всё равно могут быть проблемы, если несколько человек начинают делать какую-то длительную доработку в отдельной ветке (когда это действительно нужно). Впрочем, это уже касается любого workflow.
0xd34df00d
28.08.2022 17:07+1Действительно, что такое «страшные ченджи»? Добавление какой-нибудь новой нетривиальной логики — это страшный чендж?
DragonFire
28.08.2022 18:32Странный вопрос. Если разработчику страшно мержить то что он написал без предварительного показа то и ченж страшный.
0xd34df00d
28.08.2022 19:45+4Субъективщина какая-то.
DragonFire
28.08.2022 20:02Конечно. Зачем выдумывать какие-то метрики когда можно обойтись здравым смыслом.
0xd34df00d
28.08.2022 21:39+2Я вообще ничего не говорил о метриках. Замерять количество PR'ов, строк кода в них или комментариях совершенно не нужно.
sshikov
28.08.2022 16:19+1>А как вы ревью делаете?
А представьте себе проект, где один разработчик. Это все еще личный проект, или где? Я в таком работал пару раз, и ничего, все успешно развивалось несколько лет. Не буду утверждать, что это идеально (как раз зачастую не хватает ревью, с целью посмотреть свежим взглядом, не упустил ли я более простые способы сделать тоже самое), но такое бывает и работает. Все равно ведь я знаю, что все коммиты мои. Вот зачем мне в такой ситуации скажем pull request? Вроде уже не надо. Ну так и многое остальное очевидно можно упростить.0xd34df00d
28.08.2022 17:08+1Я как раз имел в виду личные проекты — те проекты, над которыми в основном работает один человек.
DrinkFromTheCup
28.08.2022 21:12Совсем забыл влезть с ответом в этот вопрос.
А как вы ревью делаете?
В личных проектах - никак. Совсем.
С чем-то серьёзным, где реально кодить надо было, - не доводилось вляпаться в ситуацию, когда PlayNite (и его основа .net) допускал больше одного варианта реализации нужной мне (крайне минималистичной) логики, знай себе, копируй-вставляй-передёргивай-тестовую-сборку. Да комментами присыпать погуще, чтобы когда встанет потреба что-то подпереть - не искать концов и не сидеть мордой в клаве, пытаясь вспомнить, а зачем я вообще делал то-то и сё-то.
С модами - почти аналогично. Мало какой модкит даёт серьёзно отличающиеся варианты для выбора.По работе же... тоже никак. Не кодер я. Не кодер. Но.
Моему перу по состоянию на 2016 год принадлежало порядка 10% актуальной внутренней документации по игромеху "танков". Что неприлично много для, по сути, сраного саппортёра среди 1.5к куда более закалённых и отточенных кодоворотов. И судя по тому, что мои черновики регулярно тырили себе программисты да тестировщики, получалось неплохо.Процесс выжимания документации из сорсов крайне близок к процессу код-ревью, с моей точки зрения.
В обоих случаях производящий работу должен как очень хорошо ориентироваться в чужом коде, так и очень хорошо понимать, какой результат от работы этого кода ожидается.
И в обоих случаях "коммитная дисциплина<> парадигма использования одной или нескольких веток для регулярной разработки". (чёрт, спросонья не в ту сторону знак сравнения поставил...)(что же творилось на код ревью у истинных программистов наших - прошу понять и простить, это совершенно не моего ума дело, хехехехехе...)
vkni
29.08.2022 15:27Мой хороший знакомый, фактически друг, работает сейчас в конторе, где они делают рецензирование post-merge. То есть, сперва разработчик пишет, потом сам тестирует, потом сливает, а потом оно рецензируется. И таки оно много лет так работает (в trading). Понятно дело, что люди там не совсем с улицы набраны.
0xd34df00d
30.08.2022 00:07+2Ну, я тоже что-то там в трейдинге поделал, и мы ревью делали постоянно, даже на самые мелкие изменения (просто чтобы не задумываться, фигачить в мастер или так). Хотя там тоже люди не рандомные, и я там часто в комнате был единственным без PhD.
Gugic
28.08.2022 02:24+1Может да, а может и стоит иногда выйти за пределы парадигмы гитфлоу (которая не является серебряной пулей и тащит за собой кучу проблем) и внимательно посмотреть по сторонам?
Но это неточно.
kit_oz
28.08.2022 12:06+5А что не так? Любые гит-флоу организуют работу команды вокруг одной ветки, куда все по итогу сливают свой код. А все эти фича-ветки простор помогают в этом.
Stingray42
27.08.2022 22:54+12- А зачем нам джира, когда есть VCS? Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
Человек, который обнаружил баг - это пользователь системы. Ему тоже предложите пул реквест сделать?
В статье, конечно много правильных мыслей, но подача слишком однобокая.
ninJo
28.08.2022 00:58+10Уберите эмоции и получится дельная статья с конструктивной критикой
xeeaax
28.08.2022 17:33+3Заменить прямой учет багов на проде на какие-то метрики CI/CD - это конструктивная критика?
Или может предложение использовать GIT для регистрации дефектов вместо JIRA?
Или креативная идея обязательно применить Trunk Based работу с 1 веткой не вдаваясь в реалии конкретной команды, продукта и требований к нему - тоже конструктив? Остальные подходы ведь придумали злые эффективные менеджеры, даже Scaled Trunk-Based.
stas1212
28.08.2022 01:18+5Бывало и у меня хтонический ужас висел - куда без этого при сидячей работе
Dmitresso
28.08.2022 09:40+16«Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.»
Во Вторую мировую войну венгерскому математику Абрахаму Вальду, работавшему в нью-йоркской лаборатории SRG, поручили найти решение важной задачи. Не все американские бомбардировщики возвращались на базу. А на тех, что возвращались, оставалось множество пробоин от зенитной артиллерии и истребителей, но распределены они были неравномерно: больше всего на фюзеляже и прочих частях, меньше в топливной системе и намного меньше — в двигателе. Значило ли это, что в пробитых местах нужно больше брони? Вальд ответил: нет, исследование как раз показывает, что самолёт, получивший пробоины в данных местах, ещё может вернуться на базу. Самолёт, которому попали в двигатель или бензобак, выходит из строя и не возвращается. Поскольку попадания от вражеского огня на самом деле (в первом приближении) распределены равномерно, укреплять надо те места, которые у вернувшихся в массе наиболее «чистые».xeeaax
28.08.2022 18:20+1На мой взгляд это не работает в данном случае, т.к. тут "один и тот же самолёт".
HellWalk
28.08.2022 10:22На мой взгляд есть простой показатель, который показывает куда движется проект - в сторону деградации (что бывает чаще всего), или в сторону улучшения. Показатель, конечно, не 100% верный, потому что все можно подделать. А чтобы подделать его было сложнее - я бы вообще не говорил команде, что его замеряю.
Показатель простой. Раз в неделю/месяц, берутся все задачи в трекере, и считается, какой % из этих задач был типа "ошибка/баг".
Соответственно, если каждый месяц % багов от общего количества задач растет - это тревожный сигнал. Раз встречал проект, где багов было 80% всех задач. Т.е. команда практически все время только и делала, что правила бесконечные баги (проект был без авто-тестов и CI/CD), показательно, что проект потом переписывали с нуля.
Конечно, этот показатель сработает, если в команде принято за правило все изменения по коду делать через создание задачи в трекере. Потому что, опять же, встречал команды, где была какая-то фобия на создание задач об ошибках. Как будто если задача не создана - то и ошибки вроде как и не было.
Вообще все упирается в компетентность менеджмента, и его вовлеченность в проект. При желании все решается и довольно просто. Например, чего не встречаю, а хотелось бы - чтобы программистов больше делили по разным сервисам, которыми занимались бы только они. Соответственно по количеству ошибок в том или ином сервисе будет легко понять, кто пишет код нормально, а кто тяп-ляп и за кем надо постоянно перепроверять и доделывать.
cArmius
29.08.2022 09:04+1Ради интереса - % это доля от числа задач, иди доля от числа потраченного времени?
Грубо говоря, хуже ли 10 багов по 5 минут чем 1 баг на час?
Akon32
29.08.2022 17:25+2Если проект конечный, то к завершению все фичи сделаны, а вот баги ещё есть. В вашей метрике с приближением проекта к завершению процент
бардакабагов будет расти, хотя ситуация не обязательно ухудшается.
lxsmkv
28.08.2022 10:35Показалось, что вы спроецировали моменты из статьи на какой-то свой прошлый негативный опыт.
michael_v89
28.08.2022 12:36+30Какая чушь. Кто это плюсует? Это проявление какого-то стадного инстинкта против Тинькофф-банка и менеджеров, независимо от сути написанного? Человек грубо высказывается в адрес другого человека на основе своих домыслов, нестандартных подходов к разработке, и бессмысленных высказываний.
(не имею никакого отношения к банку Тинькофф и не высказываюсь в защиту их бизнес-решений, говорю исключительно о логике)
Без единого подхода к метрикам соотнести команды между собой очень сложно
У вас же есть CI/CD, значит и метрики есть.Вы подменяете понятия и с этим спорите. Автор исходной статьи говорит о том, что не было единого подхода к анализу метрик при их наличии, это понятно из контекста.
а какой команде стоит обратить внимание на качество своей разработки
А вы считаете, что в принципе не бывает команд, которым стоит обратить внимание на качество своей разработки? А если бывают, то как это определить?
Irintus первым делом начала смотреть на то, что уже работает. Ведь зачем приходить в компанию с набором готовых, рабочих практик
Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".
Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?
Да, это называется CI/CDОбщепринятое понимание "CI/CD" заканчивается после deployment. Поэтому статистика по ошибкам, которые появились после deployment на прод не называется CI/CD.
Практика разбора дефектов была у многих команд, но носила стихийный характер.
Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.В исходной статье речь идет про разбор (анализ) человеком ошибок на проде, найденных пользователями или другими сотрудниками организации, а также тестировщиками на тестовом сервере. Вы почему-то относите к этому автоматизацию процесса разработки и приписываете автору, как будто она это сказала. Вдумайтесь в безумие этой фразы.
Юнит тесты, интеграционные тесты и тесты на продакшене, все слиплось…
В процитированном фрагменте из исходной статьи не идет речь про юнит-тесты, при чем тут они?
Удобство, интеграция с IDE, CI/CD. Незнакомо… непонятно...
Непонятно здесь только вам. В исходной статье говорится, что это команды по-разному обозначали такие задачи в трекере. "мы насчитали шесть разных подходов к разграничению дефектов".
График закрытых дефектов должен быть приближен к графику заведенных
больше нельзя заводить TODO, и обсуждения, нельзя писать RFC, иначе графики не совпадут.С чего вы взяли, что любая задача в трекере в их компании считается дефектом? По каким причинам это вообще можно было предположить? Такого ни в одной компании не бывает, всегда есть задачи с багами и есть задачи на новую функциональность, которые не считаются багами.
Новичок задает вопросы? Так делать нельзя, график вверх – плохо.
У вас на каждый вопрос новичка заводится задача с багом? Дело ваше конечно, но у остальных не так.
Разработчики, новенькие и техническая поддержка не должны общаться напрямую, это поднимает линию вверх, а вверх это плохо.
Каким образом прямое общение кого бы то ни было связано с количеством задач с багами, по которому строится этот график?
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
Именно большое количество говорит о том, что в процесс не вовлечен программист, потому что написал и даже простые кейсы не проверил. Либо о плохом качестве кода, который разваливается при любом изменении.
команда тестирования не пропускает релиз потому, что получит по башке из-за «дефектов на проде»
Если команда тестирования нашла баг, нафига пропускать его на прод?
Вся сила CI/CD в том, что, работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно.
Что за чушь? Общепринятый подход это отдельная ветка на задачу. В main ничего не пушится напрямую, на это прямо ставится запрет в настройках системы управления кодом.
Такой подход неявно предполагает, что прод и дев это два разных пайпа или бранча, которые отдельно поддерживаются.
Нет, это вы так предполагаете. В исходной статье говорится про тестовые среды, а не про ветку для разработки. Вы не знаете, что такое сервер для тестирования, на который выкладывается задача для проверки перед мержем в main?
станут звучать рациональные вопросы.
А зачем нам джира, когда есть VCS?Если у вас маленькое приложение на 100 файлов, единственными пользователями которого являются программисты, то вам низачем.
Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
Финансист, который работает во внутренней финансовой программе, может сделать пул реквест? Даже если он изучает программирование по вечерам, никто ему не даст доступ к кодовой базе проекта.
Это не рациональные вопросы, это чушь какая-то.
было создано 530 дашбордов качества
когда ни работники, ни начальство не понимает, зачем нужны метрикиЭто вы похоже не понимаете, что бывают ИТ-отделы с десятками команд и сотнями разработчиков.
Вывод. Автор не знает, что такое тестовая среда, зачем нужны таск-трекеры, как организована работа в команде в большинстве продуктовых компаний, при этом лезет поучать других в грубой форме.
ApeCoder
28.08.2022 16:32+2В целом согласен
Если команда тестирования нашла баг, нафига пропускать его на прод?
Такое возможно если баг не существенный, а какая-то функциональность срочно нужна
michael_v89
28.08.2022 16:48+2Это понятно, в таких случаях делается обсуждение с лицами, принимающими решение, и по результатам пишется комментарий в задаче "Такую-то ошибку решили исправить после выкладки, задача на исправление такая-то". К тестировщикам нет претензий, и им нет необходимости упираться рогом и не пускать релиз на прод.
davaeron
28.08.2022 18:36+1Приходить без анализа существующих? "Я принесла вам рабочие практики повышения производительности сборки тракторов. Как вы не собираете трактора? Мне вот аноним в интернете сказал, что надо приходить с готовыми практиками, так что будем внедрять практики сборки тракторов".Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
До изменений они там уже были:
в каждой команде (были) свои процессы и подходы к метрикам - из "Сказ про то, как мы метрики качества внедряли"Далее, по тексту "Сказа", менеджер уничтожил старые метрики и сделал новые.
ads83
28.08.2022 20:05Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера
А автор владеет информацией, что там у компании и разных команд было?
Я спрашивал, но не получил ответа на вопрос, насколько автор знаком с внутренней ситуацией.
michael_v89
28.08.2022 20:19Возможно автор имел ввиду ввиду, что у компании уже были свои рабочие практики (метрики), а не у менеджера.
У автора тут претензия к выражению "стихийный характер". В той статье оно относится к практике именно разбора дефектов, то есть как раз к тому, что они были, но анализировались недостаточно. Она не о том, что одни метрики заменили на другие, а о том, что по существующим метрикам добавили анализ.
davaeron
28.08.2022 20:56Мы с вами разные статьи прочитали?
Я прочитал статью "Сказ про то, как мы метрики качества внедряли", где топ-менеджмент поставил задачу руководителю по обеспечению качества, Ирине, выработать единую метрику, чтобы сравнить команды разработки между собой.
Ирина выработала набор метрик, который теперь является единым всей компании - теперь это метрики по дефектам.
Если раньше какая-то команда оценивалась по Scrum метрикам, то теперь Scrum метрики не используются для оценки эффективности команды, теперь используются новые метрики по дефектам от Ирины.
ED-209
28.08.2022 21:10Автор данной темы вероятно имеет ввиду, что введение новых метрик приведет на длинной дистанции к ухудшению качества разработки. Матерые разработчики разбегутся, а у новичков будет ориентир исключительно на показатели. Обычно такие "новшества" подразумевают под собой сокращение расходов. Ну, а что означает изменение вектора компании на сокращение расходов и так все знают..
michael_v89
28.08.2022 21:19Про Scrum метрики или замену одних метрик на другие в той статье ничего нет.
Вот что там есть.
"Практика разбора дефектов была у многих команд, но носила стихийный характер."
"Так мы поняли, что статистику дефектов, ее анализ, постановку целей по улучшению и SLA мало кто делал."
"[в существующих подходах] мы смогли выделить четыре варианта разделения дефектов теста и прода. По полю: Type, TI Environment, Bug Environment, Bug Category."
"Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным."То есть данные были, статистики по ним не было, после этого появилась с минимальным изменением в существующих процессах.
davaeron
28.08.2022 22:16В самом начале
При этом в каждой команде свои процессы и подходы к метрикам.Т.е. у каждой команды были свои метрики.
Практика разбора дефектов была у многих командУ многих, но не у всех. У оставшихся не было практики разбора дефектов. Но так как метрики были в каждой команде (см. предыдущую цитату), значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.Что произойдёт с метриками команд, у которых были другие метрики? Риторический.
Полностью исключить вмешательство в процессы команд не получилось, но мы сделали его минимальным.Это по словам менеджера Ирины =) У нас нету реакции программистов на эти нововведения. Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
michael_v89
28.08.2022 22:36значит у этих команд были какие-то другие свои метрики, на основе которых определялась эффективность команды.
Нет, возможно метрик, связанных с дефектами или эффективностью, у них просто не было. Так бывает, команда просто пилит задачи.
Что произойдёт с метриками команд, у которых были другие метрики?
Новые метрики добавятся к существующим, это самый вероятный вариант. Предыдущие метрики были зачем-то нужны, новая их полностью не заменяет.
У нас нету реакции программистов на эти нововведения.
Это не значит, что надо это додумывать и высказывать грубости в адрес менеджера, как в этой статье.
Т.к., судя по статье, теперь программистам для каждого проекта надо вести свой дашборд качества.
Вы похоже не понимаете, что такое дашборд. Это автоматизированный график, который строится по метрикам небольшим скриптом. Собственно, их для этого и собирают, чтобы потом вывести в каком-то наглядном виде и проанализировать. Раз он автоматизированный, то его никому вести не надо, он строится сам при открытии страницы. А данные для него они заносили и до введения новой статистики (поля Bug Environment и т.д.).
davaeron
28.08.2022 23:21он строится сам при открытии страницыВ итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.Дашборд создаётся вручную, к нему указываются фильтры для Jira, ключи проектов, типы задач и прочее. Всем этим фильтрам надо следовать и добавлять новые в дашборд, если они появились.
Я про это ведение дашборда.
У них уже 625 дашбордов и каждый месяц количество дашбордов увеличивается на 30 (10 качества+20 базовых).
michael_v89
29.08.2022 09:26Всем этим фильтрам надо следовать и добавлять новые в дашборд
Я не понимаю, что вы подразумеваете под словом "следовать". Фильтры заданы, им следует скрипт, который строит запрос к данным. Что вы хотите добавлять в дашборд, тоже непонятно. У нас есть конкретные фильтры, которые нас интересуют, зачем туда добавлять что-то постороннее. Дашборды общие на команду, и с большой вероятностью занимается ими тимлид, которому за управление командой компания платит деньги.
Судя по видео, многие дашборды строятся на несколько месяцев, и возможно поэтому надо их адо раз в месяц обновлять на новые даты. Также имеет значение период, на сколько месяцев он строится. Построили один дашборд на 3 месяца, потом решили "Не, что-то мало, лучше 4 сделать", и сделали другой на 4 месяца.
В общем, нет никакой проблемы в том, что у компании с несколькими сотнями разработчиков есть 160 графиков для разных показателей. 10 команд по 10 показателей на каждую, это уже 100 разных графиков.davaeron
29.08.2022 17:17+1Один раз назначить сквозной тэг команде, который она будет везде ставить в коммитах и тасках, а потом автоматически брать все проекты компании, фильтровать по тэгу и выводить в 1 дашборд на команду? Не, это слишком просто, пусть тимлиды вручную с дашбордами трахаются.
michael_v89
29.08.2022 17:27Какой еще тег, чем он отличается от ссылки на проект? Такое ощущение, что вы ищете лишь бы к чему придраться.
который она будет везде ставить в коммитах и тасках
Да, вместо того чтобы тимлид один раз в месяц задал нужные настройки в интерфейсе создания дашбордов, будем заставлять всю команду каждый день в каждом коммите и в каждой задаче вручную ставить какое-то специальное значение. Это не проще, а сложнее.
denis-isaev
29.08.2022 22:44Зачем команду заставлять? Джира сама умеет заполнять всякие кастом поля кастом значениями по каким-либо критериям.
davaeron
30.08.2022 00:29Я вам больше скажу, даже тэгов не надо. В Джире и так есть разбиение по командам и статистику из Джиры по закрытым issue можно и так прекрасно собрать.
А если нужна статистика по репозиториям, то в коммитах есть email автора. Берём его, находим в Джире его аккаунт - вот и понятно к какой команде он относится.
Сделать скрипт и запускать его ночью, чтобы он пробегал по всем репозиториям в компании, делал статистику по Джире и делал отчёты для менеджмента, как раз к их утренней чашке кофе, в разрезе по каждой команде разработки отдельно со сводным по всем командам.
michael_v89
30.08.2022 01:18и статистику из Джиры по закрытым issue можно и так прекрасно собрать
Ну так автор той статьи так и сделала.
Сделать скрипт, чтобы он делал статистику по Джире и делал отчёты для менеджмента
Ну так их Team meter и есть такой скрипт.
davaeron
30.08.2022 06:23А зачем тогда загружать ручной работой программистов? Почему dashboard per project? Почему так и не сделали сводный отчёт для топ-менеджмента?
michael_v89
30.08.2022 09:10Откуда вы взяли информацию про загрузку ручной работой программистов? В той статье ничего подобного нет.
Почему dashboard per project?
Я так понимаю, потому что основная цель была отслеживать качество по отдельным проектам.
user5000
28.08.2022 12:44+2Уважаемый автор, ваши эмоции более-менее ясны, но над текстом всё же надо поработать - ведь это не так-то и просто - понятно и доходчиво излагать свои мысли.
abar
28.08.2022 13:12+19Наглядная демонстрация почему программисты вместо того что бы стать чем-то вроде масонов, держащих мир за глотку, все больше и больше становятся чем-то вроде сантехников, крутящих типовые гайки типовыми инструментами. Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
Выступил менеджер, поставил проблему, нарисовал пути решения, показал графики, расписал процесс. Ворвался программист, заорал что-то невразумительное, потряс каким то мистером Сиай Сиди, всех обосрал, ничего вразумительного не прибавил. Когда он свалил все культурные люди выдохнули, и продолжили обсуждать цвета графика для нового дашборда.
psycho-coder
28.08.2022 16:32+1Грамотного сантехника еще найти надо. Это не только гайки крутить типовым инструментом. В IT, кстати, тоже типовые гайки и типовые инструменты.
vkni
29.08.2022 15:35+2Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
Это некоторая иллюзия. Безусловно "незаменимых нет", но также безусловно "кадры решают всё".
См. Брукса — любая замена/добавление людей в команду замедляет разработку. Если этим заниматься чересчур активно, то замедление может быть просто фатальным — у любого проекта есть некоторое окно, в течение которого он должен быть завершён, иначе он перестаёт быть интересным и тихо гибнет в корпоративных катакомбах.
alexlifewords
29.08.2022 19:22+1Может и получающими пока ещё высокую зарплату, но уже будучи абсолютно заменимыми без каких-либо потерь и сожалений.
раскройте, пожалуйста, этот тезис с аргументами.
я правильно понимаю, что программиста с высокой зарплатой можно заменить без потерь и сожалений на другого, менее опытного и с зарплатой ниже?
lovermann
28.08.2022 14:01+5Основная мысль ясна, но подача материала вызывает ещё больше вопросов к и без того не очень читаемому тексту и очень сильно ветвит обсуждение. Почитал комменты, - такое ощущение, что много людей поняли текст по-своему, поэтому складывается впечатление, что обсуждают вообще разные тексты :))
raamid
28.08.2022 15:16+22Я вот тут подумал ... а что если ... есть такой Хабр для менеджеров, где ругают программистов?
Conung_ViC
28.08.2022 16:29был. пару тройку лет назад... как там его.... чорд...
третий портал хабра, вместе с гиктаймсом был...
даже нагуглить щас не могу...
ED-209
28.08.2022 17:53+2Вряд ли. А че их ругать? Им сказали, они делают. Обычно ругают тех, кто выше по статусу и непосредственно влияет на процессы.
Пользователи ругают программистов: криворукие
Программисты ругают менеджеров: сроки
Менеджеры ругают руководство: планы, задачи
Руководство ругает владельцев бизнеса: деньги жмут
Владельцы бизнеса ругают страну: налоги, штрафы, проверки, санкции
Страны гавкаются с другими странами.
Firsto
28.08.2022 18:59+15- Designer 101-404 приступим. Готовы?
- Готов.
- Ваша контрольная фраза.
- Кроваво-черная заливка залила группу слоёв, связанных внутри, слоёв, связанных внутри, слоёв в едином макете и явственно, до жути на бекграунде тьмы ввысь белым бил логотип.
- Правки.
- Правки.
- Вам дают правки? Вносим.
- Вносим.
- Доводилось ли вам работать сутками? Вносим.
- Вносим.
- Когда вы не исполняете обязанности, вас держат без кофе? Вносим.
- Вносим.
- Одобрено.
- Одобрено.
- Что вы чувствуете держа в руках ТЗ? Одобрено.
- Одобрено.
- Вас просили играть со шрифтами? Одобрено.
- Одобрено.
- Вы жаждете вносить правки? Одобрено.
- Одобрено.
- Вам снится клиент? Одобрено.
- Одобрено.
- Вы и проджект менеджер. Связаны.
- Связаны.
- Вы чувствуете, что вам чего-то не хватает? Предоплаты.
- Предоплаты.
- Никакой предоплаты.
- Никакой предоплаты.
- Повторите три раза "Заказчик и сам так нарисует"
- Заказчик и сам так нарисует. Заказчик и сам так нарисует. Заказчик и сам так нарисует.
- На этом все. Designer 101-404 стабилен.
ReadOnlySadUser
30.08.2022 00:52+1Никогда не понимал этой сцены в бегущем по лезвию. Знаю, что там что-то из Набокова, что там какой-то тест машины на обретение разума, но чёт всегда было лень разобраться в чем суть...
davaeron
28.08.2022 21:57+3@nneeoo спасибо, что написали статью. Может изложение, как тут пишут, "от Олега" и эмоционально, но зато от души.
После вашей статьи я прочитал статью @irintus.
В той статье нет самого главного: причины, по которой понадобились эти изменения.
В самом начале текста у Ирины есть целеполагание: топ-менеджмент захотел инструмент, чтобы "соотнести команды между собой", но в статье нет ответа зачем это понадобилось менеджменту =)
И если подвести итоги той статьи, то:
Дашборд для топ-менеджмента так и не был создан. Т.е. задача не была выполнена.
Программисты Тинькоф теперь должны не только писать код, доументировать, Jira и т.п., но и вести свой дашборд качества. Т.е. топ-менеджмент создал дополнительную нагрузку на программистов, хотя отчёты нужны менеджменту, и, как мне кажется, менеджмент и должен заниматься этими отчётами.
nneeoo Автор
29.08.2022 08:13+2В той статье нет самого главного: причины, по которой понадобились эти изменения.
Мне показалось, что причины обозначены в самом начале статьи, где команды "должны были обратить внимание на качество своей работки". Если менеджер так говорит, значит он будет снижать тебе ЗП. Proof me wrong, что называется.
Ну и конечно, итоги вы подвели абсолютно верно.
vkni
29.08.2022 15:38Если менеджер так говорит, значит он будет снижать тебе ЗП.
В конечном итоге всё упирается в прибыль, а поскольку ЗП — это статья расходов, то так или иначе поползновения в ту сторону неизбежно будут.
imater
29.08.2022 14:09+1Извините, но у статьи стойкий запах Шизофрении. Не смог разобрать этот бред, нужен опытный психиатр или человек на той же волне
wavebvg
30.08.2022 12:02У статьи стойкий запах ужасного оформления. То, что она так сильно завязана на статью в шапке -- тоже можно отнести именно к оформлению.
Если Вам действительно нужно разобраться в этой статье, Вы прочитали оригинальную и проблема не исчезает, то стоит поработать над этим https://ru.wikipedia.org/wiki/Рабочая_память моментом.
k102
29.08.2022 14:24+2Напомнило прекрасную метрику в одной из компаний где я работал: kpi = (число багов на проде) / (число человек в команде). Вывод - лучше всего метрика была у больших команд, которые ничерта не делают.
VadimKNF
29.08.2022 16:09жаль, что некогда хороший банк, который мог помогать клиентам решать их вопросы (мне за один звонок увеличили ограничение на снятие наличных, так как надо было совершить крупную покупку за нал, а я стоял как дурак у банкомата и не мог снять более 150тр), теперь самовыпиливается вот таким бездарным образом, раньше мобильное приложение тинькофф было действительно помощником, а сейчас это просто корзина с багами, при том, что они умудрились поломать то, что прекрасно работало ранее
Helga_Shinkareva
29.08.2022 16:54-1Ребята, ничего личного.....просто бизнес. Я давно ждала, как минимум - года три....когда же Банк Тинькофф перепродадут третьему лицо или его "под свое крыло" возьмет государство.
Все будет хорошо....зерно перемелется и будет мука....после будет и хлебушек....
IvaYan
30.08.2022 12:24+1И что же тогда произойдет?
Helga_Shinkareva
30.08.2022 14:11-1Все под контроль государства. Банк будет выкуплен по итогу государством.
IvaYan
30.08.2022 14:14+1Хорошо, задам вопрос иначе. Что же тогда будет хорошо?
Helga_Shinkareva
30.08.2022 14:42-1Ну если Вы думаете, что гос-банк - это плохо...Вы ошибаетесь....
Это гос-контроль и контроль отмыва и вывода денег за рубеж.
Вы наверное не в курсе - бардак был в 90е денежными потоками и коммерческими банками. Поэтому гос банку я больше доверяю . И средств и сил у них больше для автоматизации процессов и ведения бизнеса. А технологии всегда можно подсмотреть и кейсы по улучшению пользовательского интерфейса и всяких примочек.IvaYan
30.08.2022 15:16А у кого вы собираетесь подсматривать технологии, когда все банки станут государственными? Между ними не будет конкуренции (потому что акционер-то у них один и тот же) поэтому искать как и чем улучшить сервис смысла нет.
Helga_Shinkareva
30.08.2022 14:45-1И кстати, в США тоже все крупные банки и фирмы - пож контролем государства и ЦРУ. Далеко ходить не надо. Цукербегра за жабры взяли еще 2 года назад..вроде как просто переименовали в Мета...да нет, взяли под полный контроль...как марионетку...И Илон Маск на ЦРУ и ВС США работает.....
vabka
29.08.2022 18:06+6Оригинальную статью, если что, не читал.
Но сложилось ощущение, будто автор выучил наизусть четыре буквы, и решили их применять везде к месту и не к месту.Либо автор никогда не работал в 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 и логи были бы просто не нужны, как и поддержка.
Зачем нам принимать запросы от пользователей, если у нас пайплайн зелёный ну?
iBljad
29.08.2022 18:42+4Как-то раз после одной операции доктор на длительное время запретил мне все виды физических нагрузок, в том числе "половую жизнь" ©, но даже по истечении этого срока у меня не было ТАКОГО передергивания, как в посте.
Складывается ощущение, что автор вырос как специалист в какой-то одной компании с очень специфическими процессами (которые для самой компании могли быть оптимальными с учетом специфики), принял это кривое зеркало за стандарт разработки и через такую вот призму смещенного восприятия прочитал комментируемый материал.
Глянул исходную статью, всё там сделано довольно грамотно, если не забывать, что разработка нужна не для разработки ("не мешайте мне кодить!"), а чтобы приносить деньги своему работодателю.
denis-isaev
29.08.2022 23:23+3Сравнивать качество работы команд по соотношениям багов в джире — это грамотно?
Взять к примеру две команды: одна занята проверкой гипотез в каком-нибудь второстепенном продукте, как следствие имеет низкую «стоимость» бага на проде, но зато требует быстрого деплоя. И вторая команда, которая пилит финансовую платформу, имеет 10 кругов тестирования и деплои раз в полгода т.к. стоимость бага очень высока. У этих команд процесс разработки и деплоя будет разный, воркфлоу в джире разный, пайплайны разные, и даже отношение к критериям «баговости» разное. Как можно сравнивать качество работы этих команд, по графикам багов в джире?
А какая-то из команд может быть вообще эксплуатирует сторонний софт и для них баг в джире — это отражение процесса общения с вендором по поводу фикса стороннего софта.
Это похоже на сравнение качества работы команд сборки урожая по соотношению мятых плодов. Сборщики изюма вечно страдают, зато сборщики кокосов счастливы.iBljad
30.08.2022 00:58Это старая игра — на каждый подход можно придумать с десяток исключений.
Насколько я понял, эти метрики используются не только для сравнения команд, но и для отслеживания их динамики.
Но, может быть, вы знаете, как QA-хэду более лучше следить за качеством всей разработки?
denis-isaev
30.08.2022 02:01В сабжевой статье в самом начале постулировалась цель не просто слежения за качеством/метриками команд (для понимания тренда), а цель сравнения команд между собой (на базе таких спорных метрик), что и удивляет.
Без единого подхода к метрикам соотнести команды между собой очень сложно. Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
В планах — построение еще одного дашборда качества для руководителей, с помощью которого будет возможно быстро проанализировать и сравнить несколько команд в рамках одного департамента.
anticyclope
30.08.2022 06:39в рамках одного департамента
отчего бы не сделать допущение, что в рамках одного департамента не происходит и проверки гипотез и запила финансовой платформы?
а может быть в рамках одного департамента команды, внезапно, сравниваемые?
denis-isaev
30.08.2022 15:03В рамках одного департамента вполне возможно, кмк. Но сделано-то было в рамках всей компании.
ApeCoder
30.08.2022 08:38+2Можно сравнивать, но не только по одной метрике и по результату сравнения не выносить какие-то приговоры, а принимать решение присмотреться к тому, что происходит в команде.
Если есть аномалия - исследовать причины. В первом случае, например уяснить разницу между командами. Во втором попросить помечать внешние баги особым образом. Заодно будет видно насколько этот внешний софт забагован.
h4ru
30.08.2022 04:33+1Комментаторы выше, как и автор статьи, сами придумали себе злой мир с KPI, лишением премий, влезанием чуть ли не в трусы сотрудника, когда об этом в оригинальной статье нет ни слова.
Манера подачи отвратительная, как и уровень понимания материала.nneeoo Автор
30.08.2022 05:41+1Я прочитал ваши комментарии к той статье. Цитирую:
Прям есть:) Более того за ними никто не ходит и не заставляет этими бордами пользоваться, есть такие метрики только по одному из типов дашбордов качества:- уникальны пользователей: 147- просмотров 743Кажется неплохой результат, учитывая, что вряд ли туда заходят по одному, скорее всего эти борды открывают вместе с командой раз в какой-то период для ретроспективы или планирования. Также есть метрика по количеству новых дашбордов, в среднем это 10 дашбордов в месяц от пользователей, которые узнали о продукте из каких-либо внутренних источников.
Уважаемый, зря не вникали. Потому что никакой анкеты то нет. И на дашборде нет никаких индивидуальных метрик по людям, только командные. В "анкете" собирается информация о том, как люди ведут проекты в Jira, никому не интересно "Где, кто, с кем, сколько раз.".
Вы работаете в тинькове? Можете представить минимальное, не деанонимизирующее вас доказательство этому?
Если да, то я бы хотел задать пару вопросов, если вы не против.
h4ru
30.08.2022 09:49+1Да, я работаю в Тинькофф, предоставить такое доказательство могу, но это доказательство будет в формате фото, как мне лучше им с вами поделиться?
Я не против ответить на какие-то вопросы, но сразу оговорюсь, я не представитель хоть какого-то руководящего слоя, я разработчик, и мне продукт из оригинальной статьи нравится и кажется полезным, в этом всё дело.nneeoo Автор
30.08.2022 09:54Давайте попробуем в качестве доказательства фотографию с монитора, где видно фрагмент кода любого сетевого IO. Можете отправить сюда или в личку, как вам комфортнее.
И сразу вопрос. Что конкретно имела в виду irintus, когда вводила SLA? Что имелось в виду под SLA и какие действия от вас это SLA требует?
hipnosis
30.08.2022 11:27+1Может быть Service Level Agreement — соглашение об уровне сервиса, где может быть указано и время необходимое для решения задач?
Соглашение вырабатываемое на основе исследований системы где выявляется возможности и определяются значение не свойственные этой системе, а дальше вырабатывается SLA — которое является опорой для возможных улучшений системы.
Когда говорят о системе, говорят о сервисе построенного для решения каких-то задач.nneeoo Автор
30.08.2022 11:28+1А нарушение SLA обычно подразумевает компенсацию, зафиксированную этим SLA. Иными словами, это KPI.
h4ru
30.08.2022 11:28+1Если вчитаться в статью irintus, то можно обнаружить, что никаких SLA она лично не вводила, более того из коробки дашборды, о которых идет речь, не предоставляют функциональности для работы с SLA.
SLA это инициатива команды или руководства, да, оно может быть навязано для сервисов категории mission critical, но это было бы и без вышеупомянутых дашбордов.
В моей команде нет SLA по дефектам (в большинстве их нет), поэтому для моей команды эти дашборды в первую очередь это повод на встречах обсудить как мы работаем и что можем изменить, чтобы поставлять с более высоким уровнем качества.nneeoo Автор
30.08.2022 11:34Вероятно, в тинькове используется чуть иное понятие SLA. Можете пояснить подробнее, где-то в документах критерии SLA зафиксированы? Обозначена ответственность и какая-то система учета по этой SLA? И чем он отличается от KPI?
Примеры из других команд тоже подойдут.
h4ru
30.08.2022 12:24Есть документ на вики, где зафиксировано рекомендуемое время исправлений высокоприоритетных дефектов, оказавшихся на проде. В случае несоблюдения SLA по дефектам прода с приоритетами Bloсker и Critical, единственная санкция это необходимость создания документа (postmortem) с описанием причин деградации сервиса, действий предпринятых для восстановления работоспособности и возникших блокировках. В дальнейшем эти документы могут быть полезны в разборе других инцидентов.
На самом деле не на каждый случай пишется postmortem, по факту такие документы пишутся только для нестандартных случаев.nneeoo Автор
30.08.2022 12:45Опуская вики и внутреннюю документацию, которая, я подозреваю, уже была. Смотря на вещи в перспективе, как описанная irintus система помогла вам получить софт лучшего качества?
У вас есть пример успешного применения?
h4ru
30.08.2022 13:04+1Тут достаточно ответить на вопрос "Зачем нам нужны метрики и графики?". Как мне кажется правильный ответ на этот вопрос: "Чтобы было о чем поговорить".
Я прихожу на встречи своей команды, мы открываем с тим лидом наш дашборд и наблюдаем динамику нашей работы, если мы видим какие-то флуктуации в этой динамике, как положительные, так и отрицательные, мы считаем это поводом порефлексировать на тему того, что мы поменяли, почему стало лучше или хуже.
Естественно больше интересует случай, когда стало хуже. Как я говорил мы не самая обремененные SLA команда в компании. У нас молодая команда на пути становления, поэтому у нас был случай, когда количество дефектов действительно пугало, в этой ситуации мы начали просто проводить эксперименты с теми или иными подходами к работе с дефектами и тестированием. Для нас эти дашборды стали монитором успешности наших экспериментов. Считаю было полезно. Но думаю, что в компании однозначно есть и другие применения, во всяком случае регулярно находятся люди с вопросами на тему метрик во внутренних каналах, говорить за всех не могу.
Я мог бы получить все те же данные иным путем, нежели с помощью этого софта, но собственно его назначение это агрегирование и визуализаця данных.nneeoo Автор
30.08.2022 13:44Что касается общения вне команды, вы уже проводили консультации и митапы с менеджерами, которые все это внедряли?
Что интересного в этих митапах вы для себя нашли и как это помогает вашей работе?h4ru
30.08.2022 13:57На самом деле мы хорошо разобрались с метриками на дашборде, поэтому на консультации не ходили. Да, кстати, они не принудительные, туда приходят люди с вопросами.
Наша команда бывала только на демо с рассказами о новой функциональности и для чего она может быть применена, кажется, что наши потребности может покрыть базовый дашборд метрик качества, расширенный подходит для команда с более выраженной QA составляющей. Для нас после первого релиз и нескольких итераций по стабилизации были покрыты все потребности, поэтому последующие улучшения нас пока не заинтересовали.
nneeoo Автор
30.08.2022 14:15Как долго работаете в этой команде лично вы и каков возраст этой команды?
h4ru
30.08.2022 14:29Парадокс, но в этой команде я работаю дольше, чем существует команда в том виде, в каком она есть сейчас. То есть в течении долгого времени я был единственным разработчиком сервиса, команда была собрана вокруг сервиса уже позже. Я работаю около 14 месяцев над текущим проектом, команда существует ~3-4 месяца.
atoshin
30.08.2022 09:22+1Отличная статья! Автор, а вы читали https://habr.com/ru/post/672012/?
nneeoo Автор
30.08.2022 09:47Спасибо за похвалу. Эту статью я упустил, но с удовольствием прочитал сейчас.
Моя статья рассказывает про внедрение JSDD со стороны руководства, а эта указывает на лучшие практики JSDD для разработчиков.
Вместе получается отличный ликбез.
entze
30.08.2022 11:44Свойство систем приходить к стабильному состоянию. В данном случае это "кто-то, что-то как-то и зачем-то делает ну и получается какой-то результат".
Кто-то, что-то, как-то, зачем-то - не обязательно неизвестные величины, какой-то - не обязательно плохой результат. Но вот дестабилизировать систему может быть весьма просто. Можно приравнять какой-то в результате к плохому с целью наказать, не влезать в кто, что, как. Можно оптимизировать один или несколько, также не влезая.Притча
Однажды компания позвала мудреца сделать лучше. Мудрец сказал - заплатите мне пока за разговор со всеми, а дальше будет видно. 3 дня и 3 вечера общался мудрец. Вернулся @Zibsunи сказал - у вас все конечно странно, но оно работает, а если менять может стать хуже.
antarx
30.08.2022 14:51Наглядная иллюстрация конфликта разработки и топ менеджмента, когда люди вместо того чтобы договариваться и решать общие проблемы всячески мешают жить друг другу. Результат в заголовке (или нет, просто все недовольные ушли).
Правых тут, очевидно, нет. Кто виноват — сложно судить, чаще всего так бывает из-за отсутствия компетентного технического топ-менеджмента (CTO, VP of engineering etc), способного разрешить этот конфликт.
Dolios
Мама, я в телевизоре!