Да, и особенно интересна идея повышения уровня владения продуктом у devteam, чтобы упростить жизнь PO. Чаще наблюдается ситуация, когда в PO видят PdM.

Почему у по не может быть помощников? Ну т.е. он все равно sole person responsible, но что мешает ему делегировать часть подготовительной работы?

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

Но тут надо понимать, что это LeSS, с его практиками Multiteam PBR, когда все команды знают каждый PBI и решение о том кто будет делать конкретный элемент принимается на планировании. В отличии, например от Nexus, где как раз на PBR команда выбирает себе конкретный элемент для работы в последующих Спринтах.

Особенно, если про помощь от team прям в гайде и написано :)

И лучше сделать тот процесс управляемым и способствующем развитию продукта, чем игнорировать и получить ad-hoc в момент возникновения дефицита PO :)

Это да. Но в гайде целое одно предложение на этот счёт =) Как часто Вам в своей практике доводилось работать с командами, в которых devteam (почти) самостоятельно расписывала истории и только изредка обращалась к PO с вопросами "а что должно быть"?

Тут скорее вопрос - кто поможет самим PO =) Мы в обсуждении исходим из того, что они перегружены.

Это да. Но в гайде целое одно предложение на этот счёт =) Как часто Вам в своей практике доводилось работать с командами, в которых devteam (почти) самостоятельно расписывала истории и только изредка обращалась к PO с вопросами "а что должно быть"?

ну вы еще скажите что devteam перегружена ;)

По-моему звучит излишне рационально для фреймворка, основанного на эмпиризме =) Можно ведь и не пускать на самотёк, но придерживаться рекомендаций. В данном случае строгой рекомендации иметь один беклог и одного PO. Если в команде PO становится очевидным бутылочным горлышком, то продумать как отработать это ограничение - например, делегировать часть функций devteam.

Проблема не всегда в будтылочном горлышке. Даже в условиях единого продуктового бэклога, если над продуктом работает несколько команд, то появляется несколько командных бэклогов. Да, "командный бэклог" не существует в гайде, но он всегда появляется в реальности: 1. Команды проводят ретроспективу и формируют action items в бэклог, специфический для команды. Далеко не факт, что эти элементы имеет смысл включать в product backlog 2. Команда взяла PBI и провела декомпозицию. Декомпозиция выявила спайки, часть из них команда забрала в спринт. Принятые по результатам технические решения могут быть непонятны остальным командам и решения останутся у команды 3. Команда взяла PBI в спринт, недооценила и не смогла заделиверить. Останки работы намного проще выполнить этой же команде, чем передавать в новую 4. Со временем команды начинают специализироваться на каки-то частях продукта. Или на специфических user journeys: лучше знают пользователей, лучше понимают методы работы, лучше знают связанный код и проблемы и т.п. И можно приводить еще массу причин, почему образуются командные бэклоги. С каждой из причин по отдельности можно бороться, но когда их накапливается много - борьба будет отнимать слишком много времени и тормозить команды. Я придерживаюсь мнения, что если не можешь предотвратить - возглавь. Команде нужен PO, который будет полноценным PO для бэклога конкретной команды. У прдукта может быть единый PO, который отвечает за приоритеты на уровне всего продукта и который выступает в роли key stakeholder для командного PO.

Проблема не всегда в будтылочном горлышке. Даже в условиях единого продуктового бэклога, если над продуктом работает несколько команд, то появляется несколько командных бэклогов. Да, "командный бэклог" не существует в гайде, но он всегда появляется в реальности: 1. Команды проводят ретроспективу и формируют action items в бэклог, специфический для команды. Далеко не факт, что эти элементы имеет смысл включать в product backlog 2. Команда взяла PBI и провела декомпозицию. Декомпозиция выявила спайки, часть из них команда забрала в спринт. Принятые по результатам технические решения могут быть непонятны остальным командам и решения останутся у команды 3. Команда взяла PBI в спринт, недооценила и не смогла заделиверить. Останки работы намного проще выполнить этой же команде, чем передавать в новую 4. Со временем команды начинают специализироваться на каки-то частях продукта. Или на специфических user journeys: лучше знают пользователей, лучше понимают методы работы, лучше знают связанный код и проблемы и т.п. И можно приводить еще массу причин, почему образуются командные бэклоги. С каждой из причин по отдельности можно бороться, но когда их накапливается много - борьба будет отнимать слишком много времени и тормозить команды. Я придерживаюсь мнения, что если не можешь предотвратить - возглавь. Команде нужен PO, который будет полноценным PO для бэклога конкретной команды. У прдукта может быть единый PO, который отвечает за приоритеты на уровне всего продукта и который выступает в роли key stakeholder для командного PO.

Спасибо за пояснение. Теперь давай переместим эти причины на уровень команды разработки. И порассуждаем чем эта ситуация отличается от PO - почему в одном случае мы боремся за единство, а в другом полагаем, что беклог/PO нужно контролируемо разделить. 1. Команда проводит ретроспективу и разработчики формируют action items в личный бэклог, специфический для каждого специалиста. Далеко не факт, что эти элементы имеет смысл включать в sprint backlog (равно как и выносить за пределы своей специализации) 2. Команда взяла PBI и провела декомпозицию. Декомпозиция выявила специфические подзадачи, часть из них некоторые разработчики забрали себе в спринт. Принятые по результатам технические решения отдельных разработчиков могут быть непонятны остальным членам командам и решения останутся у специалистов 3. Разработчик взял сабтаску из PBI в спринт, недооценил и не смог заделиверить. Останки работы намного проще выполнить этому же разработчику, чем передавать другому 4. Со временем разработчики начинают специализироваться на каких-то частях продукта. Или на специфических user journeys: лучше знают инструменты, лучше понимают практики, лучше знают связанный код и проблемы и т.п.

LeSS в помощь :)

Макс, любую аргументацию можно довести до абсурда. Что с самой ситуацией делать? какие конкретные шаги предпримет ПО, чтобы не допустить образования бэклогов помимо продуктового и как конкретно будут решаться описанные мной выше проблемы. И, замечу, практика показывает, что даже если не признавать разделение бэклогов в мултикомандной среде, они все равно разделятся. В самом оптимистичном случае - по специализации команды.

При всем уважении к LeSS, он тоже проблемы с разделением бэклога не решает. Но хотя бы декларирует :)

Ну почему не решает? Решает же! Просто сделай все команды одинаковыми по скилам и функциональности. Делай мультитим PBR, откладывай принятие решение о том какая команда будет делать фичи до планирования. Т.е. просто следуй правилам фреймворка. И все будет норм.

Я подумаю обязательно над каждым из четырёх кейсов, чтобы предложить что-то конкретное. До абсурда совсем не хотел доводить =) только провести аналогию. Единый беклог мне напоминает строгую рекомендацию иметь одно средство личного task-tracker'а. То есть плохо когда у человека один список задач для работы, один для семьи и т.д. Это из GTD.

Скилы перебор. Согласен. В остальном все так. И это работает ;)

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

А в чем проблема с PBI после ретроспектив? В LeSS кстати есть Общая ретроспектива для всех команд.

КУда их записывать?

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

Сергей, а если их больше, чем на спринт?:)

Вот пример: техническая проблема со скоростью деплоя из-за того, что в деплое "задействован" мейнфрейм. У команды есть набор идей, как можно в условиях мейнфрейма сделать нормальный CD, но для проверки этих идей им надо прогнать спайки.

Команда сгенерила, условно, 5 потенциальных решений, каждое из которых проверяется спайком от 1 до 3 дней.

В общий бэклог, продавать РО.