1-2 недели это действительно дофига. У нас, ревью после доделки задачи ревьюером, ну или переключения на что-то.

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

ага

А какой объём работы, как долго разработчик пишет код до выдачи на ревью?

по разному. Если это фича, то PR может быть огромным

еще одна проблема в том, что людей с компетенцией делать ревью меньше, чем разработчиков

Вот это плохо, мы от такого стараемся уходить, т.е. если фича получается длинной, то бьем на логические куски и сердит по частям. А QA отдаём, когда все закончили. Но на каждый MR гоняем регрессию.

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

Я думаю отчасти в этом и трабла что ревью не делают - MR-ы конские, кому охота пару дней засадить на него.... Короче кмк проблема в том что задачи бьются плохо, а не в ревью

это безусловно проблема :) особенно, если есть менеджер, который трясет по задачам и ему плевать, что кто-то выкатил мерж, который писал пару месяцев и чтобы его просто прочитать внимательно нужно несколько дней :)

Там и править по идее, если будут замечания по реализации ( не синтаксису), тоже можно нсколько дней.
Как-то давно пришел к примерному размеру дробления на подзадачи. Подзадача не больше 3х дней. Если больше, то дробить еще.

Тут уж от разраба еще зависит - какимто даш на 3 дня, они 2.5 прокопаются чтобы узнать что все пропало

Надо под конкретную команду подбирать все это

Согласен, для сырых почти обязательны ежедневные митинги.

Мы пока не дошли до такого уровня дробления, хотя очень хотелось бы :) если удалось побить по две недели уже считаем за счастье :)

а что делать, если в процессе код ревью возникают споры по поводу кода, архитектуры и т.д. и в итого процесс затягивается на долгое время?

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

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

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

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

Соррян, может каких-то деталий не вижу, или что-то упускаю)