1 продакт 1 беклог 3 команды?

Приезжай, покажу :) Один бэклог, один продакт. Он кстати в НьюЙорк едет на конференцию осенью. Они с Ильей Павличенко доклад будут о нас делать.

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

1 продакт 1 беклог 3 команды?

Семь команд

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

Поясни (с) Москва слезам не верит. Что за фиче-беклоги?

Так, выйду с планинга - расскажу

Ок

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

интересно послушать аргументы против

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

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

У "не доводилось" есть причины

Но я смогу объяснить где-то через полтора часа

я сам никуда не тороплюсь =) в любом случае ожидание того стоит

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

Я ХЗ. У нас работает. Один бэклог.

Я ХЗ. У нас работает. Один бэклог.

а а бэклоге элементы примерно какого масштаба?

Я ХЗ. У нас работает. Один бэклог.

Может быть ошибка выжившего

или нет 😉

Или у меня confirmation bias :)

объясню - рассудите :)

мне понравился доклад с ProductSence https://youtu.be/NpbvtZV_sD8 наглядный переход идей в бэклог продукта и минималистичная приоритизация)

Приезжай, покажу :) Один бэклог, один продакт. Он кстати в НьюЙорк едет на конференцию осенью. Они с Ильей Павличенко доклад будут о нас делать.

Илья же уволился)

Илья же уволился)

В смысле?

В смысле?

В прямом, какой еще смысл может быть?

а а бэклоге элементы примерно какого масштаба?

Разного. Но к планированию бьем на истории не более 13SP

Может быть ошибка выжившего

:)

В прямом, какой еще смысл может быть?

Он сейчас у нас в Ульяновске. Сегодня был тренинг PSPO.

Он сейчас у нас в Ульяновске. Сегодня был тренинг PSPO.

На подряде?)

Я деталей не знаю, честно.

Привет! Не, ну бывает еще Chief Product Owner. Найти никак не можем пока :)

Блин. Дочитываю про Scrum@Scale. Он реально есть. MetaScrums, just like SoS's, function as Scrum teams on their own. As such, they need to have someone who acts as a SM and keeps the team on track in discussions. They also need a single person who is responsible for coordinating the generation of a single Product Backlog for all of the teams covered by the MetaScrum. This person is designated as the Chief Product Owner.

Through the MetaScrums, Chief Product Owners coordinate priorities among Product Owners who work with individual teams. They align backlog priorities with Stakeholder and Customer needs. Just like a SoSM, they may be an individual team PO who chooses to play this role as well, or they may be a person speci cally dedicated to this role. Their main responsibilities are the same as a regular PO's, but at scale: · Setting a strategic vision for the whole product. · Creating a single, prioritized backlog of value to be delivered by all of the teams. · These items would be larger stories than that for a team PO. · Working closely with their associated SoSM so that the Release Plan that the MetaScrum team generates can be deployed e ciently. · Monitoring customer product feedback and adjusting the backlog accordingly

Куда мир катится.

And nally, Avi Schneier and Alex Sutherland have been invaluable in formulating and editing this document.

Сын?

династия 😂

Сын?

да

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

Так вот, обсуждение единого бэклога и большого количества команд еще актуально?:)

конечно!

для определенности хотелось бы понять что есть "большое" количество команд. Три - это граница? До можно, после - уже нет? И есть веские причины, почему нет?

Примерно 15 человек это граница.

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

(любую модерируемую дискуссию, на самом деле)

Когда группа становится больше, она либо управляемо, либо неуправляемо разобьется на суб-группы.

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

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

И вроде как это не плохо, но как только появляется "фича", которая пересекает зоны компетенции нескольких команд, спринты взорвутся взаимозависимостью

LeSS и SAFe, кстати, эту проблему не игнорируют, просто риторика отличается :)

В LeSS появляются всякие Product Area, feature teams и т.п.

В SAFe есть разделение на ART (PI) Backlog, который бьется на Team backlogs и зависимости планируются на PI Planning

НО у меня и концептуальное несогласие с концепцией "все команды работают с одним бэклогом no matter what" :)

А если продукт один?)

А если продукт один?)

Так речь и идет о том, что продукт один

Маленькие подукты большими командами не делаются :)

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

Не совсем, но близко.

Вопрос: это опыт только с разработкой(dev)?

Не совсем, но близко.

А как?

А как?

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

Или придет новй айтем в бэклог, который пересекает копетенцию нескольких команд.

В такой ситуации даже не важно, какого размера айтем.

Т.е. вот представь, пилит 5 команд крутой магазин, практически клон амазона.

Одна команда - полностью в "корзине", спецы по платежкам, поцессингу и т.п.

Вторая - спецы по рекомендациям, что с чем связано в покупках, с какой частотой одинаковые айтемы просматривают и т.п.

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

Ну у меня сразу вопрос: а чего так разложены компоненты?

Потому что при "едином бэклоге" никто разложением не управляет.

Потому что при "едином бэклоге" никто разложением не управляет.

О! А чего?

Оно "само" происходит, и разложение на фичи или элементы воркфлоу - это еще в улчшем случае :)

Эмпирически ?)

О! А чего?

Потому что любое управление "разложением" приведет к образованию командных бэклогов или бэклогов компонентов :)

Эмпирически ?)

Эмпирически, но у этого наблюдения есть верифицируемое пояснение.

Как тогда происходит PBR и планирование? На сколько РО детально описывает эпики и ЮС?

Эмпирически, но у этого наблюдения есть верифицируемое пояснение.

Какое ?

Какое ?

Группы больше определенного размера разбиваются на подгруппы :)

Размер скрам-команды примерно из-за этого же ограничили.

7-9 человек предел для самоорганизации, 15 - примерный предел для модерируемой группы.

Этим цифрам тоже есть пояснения, но они идут очень далеко в теорию эволюции :)

Как тогда происходит PBR и планирование? На сколько РО детально описывает эпики и ЮС?

В разный фреймворках по разному. Про LeSS лучше у Сергея спросить. Детализация - достаточно детально, чтобы команда могла продолжить работу самостоятельно :)

Я обычно советую описывать сугубо конечный результат

Ну по детализации понятно.

Тогда ты имеешь в виду под модерацией группы размером не более человек: РО, Беклог - на одну такую группу? Т.е по сути две команды по 7 человек +/- 1

При иных условиях будет переломит по коммуникациям, пониманию и координации.