Как-то так.

В целом модерация может быть любой - от формального менеджера, который всем начальник, до "фасилитатора" на всех митингах

я всё еще не уловил причин, по которым Product Backlog не может быть один.. Давайте возьмем вариант Сергея, 7 команд. Да, команды отличаются в той или иной степени специализацией. Да, при работе с беклогом PO нужно будет стараться ограничивать ценности историями, выполнить которые могла бы одна из команд. Да, рано или поздно прилетит этакая хитрая история (к слову, истории не должны повторять хотелки пользователя, а всё-таки формулироваться PO, в том числе с пониманием имеющихся в наличии команд разработки), которая затронет несколько команд - возникнут зависимости.. справиться с которыми призваны разные схемы Scaled Scrum. Совсем упрощенно - дифференцировать, выполнить по кускам, интегрировать (примерно как любую историю разбивают на выполнимые задачи в рамках одной команды).. Так и что?

Так то, что это уже не единый бэклог, это бэклог продукта и бэклоги команд

Я к тому, что не надо делать вид, что это не так - на делание вид уходят силы, которые стоит потратить на что-то другое :)

В моем понимании, до тех пор пока PO выполняет свою роль инерпритатора внешних запросов в реализуемые командами разработки ценности - всё хорошо =) Ограничение системы тут ровно этот человек - PO. И от него зависит управляемый размер беклога

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

Команды будут брать то, что понимают и что могут выполнить.

Так то, что это уже не единый бэклог, это бэклог продукта и бэклоги команд

нет, пока есть один человек, в голове которого укладывается весь беклог

так можно сказать что беклог не беклог, т.к. он состоит из частей =) PBI

В лучшем случае получатся feature teams, в худшем (а в неуправляемом будет именно худший случай) - component teams

так можно сказать что беклог не беклог, т.к. он состоит из частей =) PBI

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

нет, пока есть один человек, в голове которого укладывается весь беклог

Вот с наличием такого человека у меня и есть фундаментальное несогласие :)

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

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

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

У меня был кейс: Беклог один. Была ЮС на разработку. Так вот реализовали эту ЮС аккаунт менеджеры. Было более 20 человек. Не знаю в контексте ли это нашего диалога. Но я к тому что все таки возможно модерировать. Хотя если прям всматриваться в понятие Беклога Продукта и понятие беклога команды: может мы просто о понятиях Артефакта говорим. Нежели о самом подходе?

Вот с наличием такого человека у меня и есть фундаментальное несогласие :)

человек есть же =) и я бы таки не оценивал ограничение этой системы числом разработчиков.. а именно качествами самого PO

И называя "под-бэклоги" не настоящими бэклогами, мы не устраняем необходимость этим бэклогом управлять :)

Отсюда возвращаемся к началу общения - к команды должен быть PO и 1 PO на много команд это плохо.

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

мы же не можем сказать - не делайте продутов бОльше чем можно реализовать силами 15 разработчиков и 1 PO

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

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

devops - это по сути логистика, не более

девопс это еще и культура :)

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

Которая диктует в том числе и метод формирования команд

культура - это по сути довольно высокий уровень управления

Макс, с devops есть проблема: под этим термином одновременно понимают все связаныне инженерные практики и весь комплекс менеджерских практик.

Т.е. в одном термине смешивается настройка puppet и организация потока работы внутри системы :)

В итоге слегка взрывается мозг :)

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

так до 8 команд грубо по 7-8 человек же и есть)

если надо больше, делят на Area)

так до 8 команд грубо по 7-8 человек же и есть)

Так 7 команд по 7-8 человек уже в едином контексте не работают без специальных ухищрений :)

и всё же мне странно что мы ограничиваем PO через численность разработчиков.. PO так то разработчиками напрямую и не управляет.. ему должно быть в теории всё равно 10 их или 100. PO напрямую управляет только беклогом. Управляемая длинна беклога и есть ограничение.

LeSS и Сергей говорят, что работает 😄

ART в SAFe вообще от 50 до 120 человек. Так там вокруг координации работы навернут огромный пласт методов, от инженерных до организационных

и всё же мне странно что мы ограничиваем PO через численность разработчиков.. PO так то разработчиками напрямую и не управляет.. ему должно быть в теории всё равно 10 их или 100. PO напрямую управляет только беклогом. Управляемая длинна беклога и есть ограничение.

Макс, а никто и не говорит, что ограничение - PO. Ограничение - количество бэклогов.

В LeSS их, не смотря на заявления, тоже несколько :)

ART в SAFe вообще от 50 до 120 человек. Так там вокруг координации работы навернут огромный пласт методов, от инженерных до организационных

угу, а в LeSS все само)), но работает

угу, а в LeSS все само)), но работает

Вопрос в том, как работает.

придет утром Сергей и расскажет)

Юрий, Сергей рассказывал

Я выше писал - вопрос семаники.

непонятно =) вот давайте забудем обо всём, кроме PO. С каким размером беклога он может работать, а в какой момент уже надо остановиться и сказать - давайте делать 2 беклога?

Я выше писал - вопрос семаники.

на мой взгляд главное, чтоб работало)

Объявить, что "у нас один продуктовый бэклог, а что не продуктовый бэклог - то не настоящий бэклог, а так - суббэклоги и фичи" - какбэ вариант, но управлять то всеми этими суб-эбэклогами все равно придется.

непонятно =) вот давайте забудем обо всём, кроме PO. С каким размером беклога он может работать, а в какой момент уже надо остановиться и сказать - давайте делать 2 беклога?

С любым. Вопрос в том, сколько в рамках этой работы с бэклогом ему приходится работать с людьми?

Т.е. какая у PO внутренняя группа?

Если у него внутренняя группа в 50 человек, то сколько времени у него остается на работу с вопросами и уточнениями от этих людей?

И насколько эффективной будет такая работа.

да, это важно.. но может и 1 команда разработки не вытягивать =) а могут 7 работать слаженно. Почему нет? Это и хочу понять =)

Макс, вопрос не в слаженности.

PO не нужно работать со всеми разработчиками

Команды МОГУТ работать без выделенного PO. Или с одним PO на 50 человек.

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

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

эм.. вот это важное утверждение - то есть я правильно понимаю, ты утверждаешь что PO должен таки работать с каждым отдельным разработчиком?

С каждой командой, в течение спринта

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

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

Если разработчику что-то непонятно, то он подойдет спросить. Ну или можно нагородить очень много бюрократии :)

Нет, "мосты" не работают.

Верней как. Мосты работают ТОЛЬКО если у "моста" или "прокси", как их обычно называют, есть делегированное право принимать самостоятельные решения по бэклогу.

если разработчику что-то непонятно, то он подойдет спросить.. команду! =) а не PO.. PO же не пишет ТЗ. Задача PO сформулировать ценность.

PO, напомню, отвечает за подтверждение тогО, что команда доставила ценность :)

всё так

(если слегка упростить длинную цепочку причин и следсвий создания приоритетов в бэклоге, требований и необходимости demo)

всё так

Т.е. если у разработчика возникнет вопрос "чота я вот не уверен, что правильно понял acceptance criteria, да и внутри команды мы не особо прояснили", то идти надо к PO.

Потому и важно, чтобы PO работал с командой в течение спринта.

И чтобы PBI он видел тоже в течение спринта, а не первый раз на демо :)

совершенно согласен.. но не думаю что 15 человек, потенциально подходящих с вопросами - это физическое ограничение для человека.. эмм.. у меня это человек 50 (подходящих лично или через мессенжер/телефон и т.п.)

Макс, контекст.

У PO есть и другая работа.

как и у всех =)

PO не сверхчеловек и тоже имеет ограничения.

Другая - в смысле кроме как на вопросы отвечать.

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

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

В итоге говенные решения, говенные ответы и говенные требования.

я и говорю что ограничение тут - сам PO