+1KVA wrote: 28 Jul 2021 03:38Тогда усядемся получше и бум наблюдать шоу.Херовимчик wrote: 28 Jul 2021 03:16 У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point
Ну вот оппозиция также как и вы мыслит похожеmister-X wrote: 28 Jul 2021 03:49 :+1KVA wrote: 28 Jul 2021 03:38Тогда усядемся получше и бум наблюдать шоу.Херовимчик wrote: 28 Jul 2021 03:16 У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point
Компетишен внутри теамс, когда амбиции девелоперов заставляют работать их больше и быстрее. Отличная стратегия. Пилите Шура, пилите
что если согнать по-больше крутых перцев, то все можно решить в пользу «сильнейших». При этом их не смущает что вопрос с годами встал только острее 
Мне за обязанность Бабы-Яги/Миротворца как раз хорошо доплачиваютmister-X wrote: 28 Jul 2021 04:27 Из собственного опыта я пришёл к выводу что 'инициативным' не надо мешать. Им надо добавлять работы чтобы не было сил отвлекаться на высокомерие по отношению к другим. Умный менеджер всегда таких использует. Не ввязывайтесь в чужую драку. Начальству это и нужно - компетишен чтобы не надо было мотивировать деньгами.
а нормальному начальству как раз нужно перенаправить излишки энергии в продуктивное русло, а не устраивать rat race на ровном месте 
мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...Херовимчик wrote: 28 Jul 2021 03:16 У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point
Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.alex_127 wrote: 28 Jul 2021 06:24мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...Херовимчик wrote: 28 Jul 2021 03:16 У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point
Ну так как раз чтобы не было переливания и долгих бесполезных споров. "Мы посовещались и я решил"Херовимчик wrote: 28 Jul 2021 15:27Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.alex_127 wrote: 28 Jul 2021 06:24мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...Херовимчик wrote: 28 Jul 2021 03:16 У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point
Вообще удивительно что большинство воспринимает разногласия в процессах/мнениях между командами как конфликт, который требует вмешательства authority. Обычный рабочий момент
Если за 8 лет не нашли согласия в процессах/мнениях, то и сейчас не найдете если будете nice. Если конфликт нужно решить сейчас, то это IMHO возможно только через authority (делай как я сказал, а не то ...Херовимчик wrote: 28 Jul 2021 15:27 Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.
Вообще удивительно что большинство воспринимает разногласия в процессах/мнениях между командами как конфликт, который требует вмешательства authority. Обычный рабочий момент
)
Так у нас и так делегирование - одни смотрят только со стороны архитектуры, другие только с точки зрения домена, остальные по желанию и усмотрениюVladimir Kr. wrote: 28 Jul 2021 16:13 все смешалось... PR с вопросами по архитектуре? задерживатся? и собираются вместе? из-за того, что не линкованы с другими системами?
- Если людей не хватает, то решается делегированием:
конкретно в вашем примере: (#2) должны проверять пре-апрувы доверенных TL&SME, a не ревьювить весь PR сами
- Вопросы архитектуры не должны всплывать на PR кода, архитектура решается до создания бранча
- самопиленные тулзы для линка систем? зачем, есть jira с прозрачной интеграцией процесса (тикет->бранч->PR->build->тикет), или аздо девопс gates, например https://docs.microsoft.com/en-us/azure/ ... -approvals (бранч->PR->deploy->test->merge)
- code style, code coverave, TDD/BDD, все это может SME/TL проверить - есть-ли покрытие фичи integration/functional test, или нет, соответственно апрувнуть, % покрытия и прочее; или автоматизировать - см. gates выше
вот если PR собираются, чтобы "научить и доказать", тогда надо звать authority
формализуйте правила PR не для бюрократии, а для удобства работы
1. у нас сонарклаудХеровимчик wrote: 27 Jul 2021 16:01 А давайте поговорим о безопасных (от дураков) и эффективных практиках.
Дано:
- большая code base
- 40-50 контрибьютеров (почти десяток команд, каждая со своими тараканами и традициями)
Есть у нас:
1. CLI (авторы одной из команд котрибьютеров). Тул призван к унификации гит коммита, чтобы все запятая к запятой, точка к точке и т.д. Также тул привязан к системе багтрэкинга. Вообщем, все чтобы даже мысли не было создать PR через UI и забыть любую мелочь
2. Core reviewers - люди без чьего благословенная ни один PR нельзя смерджить. Это люди следящие за архитектурой и стилистикой. Их мало, а PR траффик огромный
3. Code owners - либо владелец данного кода, либо SME. Соотношение технологий к экспертам неравномерное, так что тоже людей мало, а PR-ов много. Без их благословения тоже нельзя смерджить.
#3 и #2 это одна из доп обязанностей твоей роли, а ещё работать надо (с). Когда большие изменения, людей нужно преследовать/подкупать чтобы PR не застрял на месяцы
#1 качество такое, что народ набил руку на формат и все равно через UI делает (не, есть такие что неделями будут сидеть и ждать пока починят, остановив всю работу).
А как у вас?
Билды по всем существующим таргетам это святое!nickb wrote: 27 Aug 2021 01:52 А у нас для feature запускается свой build. Со всеми проверками, sonarqube и т.п. Без такого build-а даже нельзя сделать MR.
А code review делают тим лиды этих девелоперов