Осмелюсь предположить, что Сергей имеет в виду: retro, review, planning и daily. И вот твой кофе ☕️ Однако вопрос не такой уж простой. В обсуждениях кто-то говорит, что честный feedback в скраме только один прописан и повторяет он цикл Деминга: Plan (planning), Do (sprint), Check (review), Act (retro). Кто-то видит feedback и в PO с SM.

Я хочу именно ответ Сергея послушать. У нас не так давно была интересная дискуссия на тему циклов обратнйо связи в скраме.

завтра уже 😁

Питеру привет!)

А ты расскажешь про циклы?:)

Петли обратной связи все равно четыре ...

Я не говорю по-русски, поэтому я заранее извиняюсь. Я использую Яндекс переводчик. Я из Мексики. Есть ли в русской технической литературе какие-либо книги о методологиях работы? То есть, существует определенная аналогия между SCRUM, KANBAN с каким-то методом, разработанным в России сегодня или в какой-то другой предыдущий момент

Есть вот такая штука местной разработки (https://consulting.1c.ru/technologies/tbr/). Построена, правда, отчасти на основе Scrum, на сколько мне известно. Глубоко не копал. Подходит для быстрого запуска серийных продуктов по обкатанным схемам.

Всем привет. Кейс: есть 3 продукта, которые базируются на одном web-сайте и на одном приложении - фронта два как понимаете. У каждого фронта свой DT. За каждым продуктом стоит свой бэк: CRM, шлюз транзакций и шина, и свои DT. У каждого продукта совой PO. Кто с подобным работал? Компонентые или продуктовые команды? Почему? Что для синхронизации использовали?

Всем привет. Кейс: есть 3 продукта, которые базируются на одном web-сайте и на одном приложении - фронта два как понимаете. У каждого фронта свой DT. За каждым продуктом стоит свой бэк: CRM, шлюз транзакций и шина, и свои DT. У каждого продукта совой PO. Кто с подобным работал? Компонентые или продуктовые команды? Почему? Что для синхронизации использовали?

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

Это пахнет компонентными командами. Почините и вопрос в синхронизации будет решить проще

выглядит так как будто продукт один, а вместо PO два key account manager которые менеджат хотелки того или другого пласта клиентов.

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

Фидбэк может быть реальный, но отсутствие знаний/опыта заказчика о подобных продуктах даст плохой фидбэк

Фидбэк может быть реальный, но отсутствие знаний/опыта заказчика о подобных продуктах даст плохой фидбэк

каждая команда может сделать все

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

Хех. Если заказчик плохо знает, что он заказывает, то проблема именно в этом. Дальше вопрос - будете продвигать cover your ass development или таки будуту решать проблему ))

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

Да, он может сказать вот это мне удобно, а вот это неудобно.

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

в точку!

Ну так и поговорите об этом с заказчиком. Иначе потом он просто скажет что вы херню сделали.

При заключении контракта прописывается результат

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

Так надо заранее договориться)

Планы - ложь, это до тех пор, пока нет ответственности за планы

Стоит начать с формирования продукт вижна и найма PO

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

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

А разные технологии и инфраструктурная зрелость как? Вот как например, 3 разарботчика мобилы будут шатать одно приложение?

Не понял вопрос

И да народ в случае большой команды будет делится на компоненты :D

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

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

Ты гововорить, что нужно делать продуктовые команды. Вот смотрие, есть мобильное приложение, репа одна, есть три разработчика из разных продуктовых командах. Каждый разработчик пилит свою часть мобильного приложения получается. Как технически это выглядит? Это же сайт, модулей нет. Пересечение кода огромно.