Можно делать так что если вы в тестировании, пару раз наступили в одно и тоже дерьмо, то или сами напишите тест, или создайте задачу на разрабов.

Если вы верифите баг, то в зависимости от критичности бага(тем более если он пришел от клиента), можно настаивать на покрытии этого бага юнит-тестом.

@kami_nary lokinay Вот как это делается  в битбакете https://confluence.atlassian.com/bitbucketserver/add-default-reviewers-to-pull-requests-834221295.html  А что у вас сейчас используется для code review?

У нас пока ногами делается, остается на совести разработчиков и менеджеров проектов. Так как компания небольшая, то пока не очень критично вводить инструменты.

У нас тоже нет окончательного решения по инструментарию для code review.Планировалось использовать для этого gitlab,но все заглохло на этапе идеи.У нас нет сложностей в настройке гита или еще чего-нибудь.Проблема тут другая - не хотят,лень делать ревью.

А почему не хотят? Не осознают ценности ревью?

Лень и пофигизм, у нас многие морально выгорели

Это можно решать на уровне рабочего процесса, включать доки в DoD задач. Но от выгорания это не поможет, я думаю.

Хз, что от него помогает в масштабе всей компании.

Для меня так дико читать, что у кого-то еще нет код ревью. У нас необходимость в нем ни кем даже не оспаривается. Даже у автотестеров есть ревью. Но есть обратная сторона медали - часто пулл реквесты висят по несколько дней, а в тяжелых случаях - недель.

Угу, дичь с процессами у товарища в компании. С другой стороны может быть такой стиль разработки им подходит.
Плюс Код ревью часто проходит формально, так что он сам по себе тоже не панацея

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

Попробуйте собраться с разрабами и решить для чего делать код ревью, когда можно не делать ревью, что там смотреть, сроки ревью, обсудить между собой как выделить время на это (может у кого-то есть удобное работающее решение этой проблемы), как оповещать друг-друга о ревью и т.д. и т.п.

После этого настроить битбакет и поставить минимум 1 обязательного ревьюера (тоже проговорить это на митинге)

Могут выявиться индивидуальные особенности разработчиков: кому-то удобнее (и эффективнее) одному смотреть, а кому-то удобнее в диалоге обсудить ревью и т.д. Надо общаться, да!

Но сначала всё-таки понять принципиальный момент - готовы ли вы как команда (и разработчики и лид и ПМ и др.) инвестировать в эту технику время и зачем вам это делать. Если никто не видит в этом ценности, получается просто бездумное копирование "так же как у других" - так не надо делать. А когда все видят в этом пользу, то никого и заставлять не надо будет, всё и так будет само работать как надо

Ход мысли на слайде верный, но чтоб понять её правильно (а тем более правильно применить), нужно этот краткий тезис подробненько расшифровать, разобрать, разложить по полочкам и превратить в методику, по которой можно будет выстроить процесс.

Слишком категорично принимать - опасно!

Нельзя просто так взять и убрать тестирование :)

... превратив его всё в код...

Ваша команда как-то борется с зависанием пулреквестов на ревью? Или это пока не проблема?

Это проблема, которая пока не решена. На каждой ретре обсуждаем как ее решить, но пока не нашли такого решения, есть только некоторые направления, в которые планируем двигаться, чтобы со временем сократить время прохождения ревью

Все вспомнили про завтрашний митап?)

Это который?