Коля Алименков молодец!

Всем привет. А у меня такой вопрос. Сейчас в компании приняты MVP и что называется "х...-х.... и в продакшен". и они выкатываются на 50% (что в целом много, как по мне, но не суть). Суть вопроса в том, на каком уровне реализовать превращение mvp в production версию. Т.е. чтобы у людей не было соблазна ползунок на 100% передвинуть. Ведь уже всё готово и работает. Модель плоская, все команды самодостаточны. И ответственность на команде, но вот как привить понимание, что если катим что-то успешное в прод, то пожалуйста, добавьте тестовое покрытие, доку, метрики и т.п. Чтобы после 10-20 mvp не получить кучу не покрытого автотестами (на всех уровнях) кода. Ну и подчищать за всеми тоже не хотим.
И большая проблема, что в этой плоской системе мы одна из команд, которая должна этот возможный ппц ограничить. Т.е. у нас тут вариант, когда есть обязательства, но нет рычагов давления, прямых. И уповать на сознательность и что обучим и всё будут заиньками тоже не очень хочется.
У кого-нибудь был похожий опыт? Как решали? Что почитать?

расформировать надо вашу команду нафиг, или переименовать в "центр компетенций", чтобы ответственность была на продуктовых командах, у кого и все рычаги. Со стороны вашей команды — внедрение по тихому sonarqube или аналога и еженедельные отчёты веерной рассылкой по сравнению качества кода / покрытия / т.п. То есть вы должны быть ответственны за объективное измерение качества, а доведение фактического качества до ума — не на вас.

Я бы как продуктовик эти отчеты в спам отправлял автоматом. На кой мне чей то сонар, если стейкхолдерам все ок.

если проблем на проде нет — всё ок, хоть в спам, хоть на стенку. Но как только будут, надо, чтобы ответственность была на том, кто знал, но ничего не сделал.

однако, не помню, кто сказал, чтобы что-то улучшить, достаточно начать это измерять. И по какой-то магии наличие на стене висящего графика с оценками кода заставляет этот график идти вверх.

А это все нельзя ли запихнуть в QG  до этапа ИТ, которые будут иметь обязательный характер для всех команд в компании ?

Тогда, лопату считай придумали вы, а бить ей не вам придётся)

Знал и бездействовал) Не, я согласен, просто часто оказывается, что все полимеры уже давно продолбаны. Надо как-то через команды запихивать процедуры в их Definition of Done и прочие регламенты

не, DoD должен быть выстрадан командой, иначе ничего хорошего не будет, как и с любой попыткой навязать Agile "сверху". Но вот дать советы, что можно включить (быстро и дешёво) в DoD или в gateway pipeline — вот это командам транслировать надо.

Ну да, надо убедить, что они это сами придумали, а как иначе то)

@vlsergey это уже обсуждали. И как правильно заметил @Bugaginho сейчас впиливать метрики будем, которых не хватает чтобы показать что все плохо. И видимо на регулярной основе будем где-то про это нудеть.
@arushanchik quality gateы он хорош, но вот для mvp он должен быть один, чтобы как уже сказал "быстро и в продакшен", а для продакшен другой. Т.е. чтобы мы своей борьбой за качество не тормозили быструю проверку идей, но и не допускали скатиться в уГ кодовой базе, но возникает проблема, что мы уже задеплоили в мастер вот это вот mvp. И как бы уже QG пройдены. Т.е. нам надо исключительно измерять состояние кодовой базы в динамике и если идет деградация разбираться.
Возможно, действительно, когда мы это покажем и это будет на виду у людей, у которых в голове это будет как-то сразу в деньги пересчитываться, то может и отпадут сразу другие проблемы.

И какие интересно метрики не позволят скатиться вашей кодовой базе в УГ?

на прошедшей техлид конфе был доклад по этой теме
https://techleadconf.ru/2020/abstracts/6585

Хотя наличие любых объективных метрик ничего не гарантирует, их полное отсутствие (в том числе отсутствие метрик по code coverage, execution time и даже простого lint’инга) _обычно_ означает что код уже плох.

Спасибо. Опередили. :) Именно так.

Спасибо. Даже не слышал про эту конфу. А можно записи где-то приобрести?

Написать в саппорт онтико

Или автору доклада

Использовать подобные метрики для оценки продуктового кода, это все равно, что продуктивность программиста измерять в строчках кода. Абсолютно бессмысленно. У нас может быть кодовая база со 100% покрытием тестами и отличными метриками, но из-за технического долга продукт невозможно развивать и он не отвечает требованиям бизнеса.