Подобно смогу попозже. Сейчас в пути

А можешь скинуть гифку, где Феликс говорит Ня?

Сложное задание

@chaoscode  что происходит?_))

Нос лисы 🦊

ого! большой_)

описываю подробно;  надо принять что не все работает работает идеально и в том что я описываю отчасти то что хочется сделать,  но не внедрено еще.

- есть scrum спринты две недели
- в начале спринта планирование на котором оцениваются задачи сверху бэклога, пока не забьется по велосити.
- можно принять определенные соглашения, как определять что задачу стоит декомпозировать. Это индивидуально для команды и подхода. Делать больше дня. Больше определенного числа SP.
- мы понимаем что команда продуктовая и есть фронт и бэк.  И поэтому велосити считается отдельно на бэк и фронт
- должен быть запас задач в бэклоге если команда сможет сделать больше чем заложили по велосити.
- каждый день дейли, идем по доске, говорим только продуктово. Любые технические проблемы после дейли только с заинтересованными
- в середине спринта груминг или еще называют product backlog review.  К нему должны уже быть подготовлены проработанные задачи, с конечными макетами и историями. Возможно на груминге будет принято решение их декомпозировать. Всей команде на всем груминге быть нет смысла, пересечение по задачам в которых заинтересованы и бэкеры и фронты может быть небольшое. Тут нужно играть с временем. Дробить встречу.
- важно чтобы груминг был цикличной встречей. Иначе на него будет забиваться, он будет забываться.
- Если задача сложней чем 1 компонент с простой формой, и разработчик, то возможно стоит выделить минут 20 на проектирования, где разработчик расскажет техлиду или всей команде (это индивидуально для каждой команды)  как он собирается проектировать. Это может сильно сэкономить ему иревьюверам   время на ревью и само кодирование.
- Как забивать бэклог. Продакт и дизайнеры могут работать  также по доске как и разработчики. По тому же флоу. Они ставят себе задачи, делают их и отправляют на ревью команды. Плюсы - разработчики дают обратную связь понятно ли все. Разработчики могут обладать экспертизами которые помогут сориентироваться продактам и дизайнерам и внести корректировки до того как задачи попадут в бэклог. И не нужно собирать для этого встречу.
- Соглашения. Разные, типа задача должна быть проревьювлена не позже чем за сутки. Если задача по кодингу большая и не раздробить на несколько независимых, то все равно как можно  сделать - отбранчевать от мастера ветку по номеру задачи  , и от нее бранчевать ветки, делать MR/PR маленьких веток вида номерзадачи-stage-1 (я фантазирую) и делать MR/PR с основной веткой "номер задачи". Причины очевидны - большие MR/PR очень тяжело проверять. Сложность растет по экспоненте.  Легко пропустить косяки.
- Definitions of Done. Чему должна удовлетворять задача чтобы ее можно было переместить в след столбик на доске
- в конце спринта демо для компании и ретроспектива. Ретроспективы кстати бывают очень разные. есть например архитектурная когда рисуют UML  проекта. Детализация индивидуальна. У всех же разные проекты. И все вешают стикеры на части проекта как считают нужным. Затем голосуют обсуждают; Есть timeline ретро. очень давно не проводил. Проводят по итогам запуска чего либо большого. НАпример большой фичи. Чтобы разобрать что когда происходило и к чему это привело.


впринципе даже вот этого уже должно хватить чтобы бОльшая часть болтовни стала систематезирована

всего типов ретро вроде порядка 30-40

ты про что?

ты все время у меня пишешь_)

ну как видишь я писал))

перформинг включает в себя и перформинг всех встреч. Любой флуд пресекается

Я дочитал)

))

по факту это тоже инженерные практики, весьма точные)

Норм устроено

мне в свое время помогло много изучать по agile. Само по себе грамотное внедрение agile и грамотные ретро норм перформят и решают проблемы

Мне от вас, кстати, письма приходят с предельно точным временем визита до. Типа до вашего визита осталось 1 час 3 минуты. Это фича?