Можно ли считать, что я как ключевая заинтересованная сторона нарушаю

гайд поднимая на ревью вопрос о препятствиях помешавших команде достигнуть целей спринта?

Могу ли я как владелец ресурсов не согласиться с аргументацией касающейся требования ресурса?

Уточните, пож-та, "ключевая заинтересованная сторона" - заинтересованная в чем?

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

В чем Ваш интерес? В чем цель Вашего присутствия на ревью?

Я тот с кем PO согласовывает цели спринта с позиции соответствия бизнес интересам

А что ещё РО с Вами согласовывает?

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

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

Вообще ничего не понятно.

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

Откуда такое требование?

Сейчас опытный ресурсный менеджер тебе расскажет про эффективную утилизацию ресурсов.

Ух) пассивная агрессия часть навыков psm3? 😂

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

Я допускаю обсуждение эффективности и обоснованности такой схемы организации работы, но не с позиции скрам гайда )

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

Расскажете как зачем занять верстальщика на фултайм в одной из продуктовых команд? Чем его фултайм участие поможет достижению бизнес целей?

Фокусом на Цели спринта

Скрам гайд это короткая инструкцая написанная общим языком, вы же понимаете, что такой сложный процесс как организация работы комагды по оазработке ПО в него в принципе умнститься не может

Команда в состоянии ответить на этот вопрос самостоятельно.

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

Завсит от обьёмов, если объёмов мало может участвовать, как приглашённый экспнрт, но разрабы, аналитики и тестировщики обычно выделяются на фултайм

Смайл забыл :)

Именно. И если принято решение не включать в проект ряд специалистов на фулл тайм - это не означает что скрама не получится

Моё мнение, что Скрам мастер отвечает за все что касается, процессов, метрик, мотивации команды, механизмов непрерывного улучшения и вообще всего что связано с эффективностью. Если при этом он может дать советы по производственному процессу - тоже круто. Но как именно писать код он не должен знать и советовать не должен. Если я понял вопрос

Если только он не совмещает роли разраба и СМ...

А каких конкретно специалистов вы не включили?

Никого кроме Лида, который понимает как превратить бизнес требования в запрос на изменение и спустить этот запрос в разработку

Ну по факту он у вас аналитик. И он обязательно должен быть в команде. Иначе это большая проблема

Он в команде)

Он на фулл тайм в команде? Тогда я запутался. А кто не в команде?

Верстальщик 😎

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

В команду включен только Лид. Остальные инженеры вне конкретно этой команды

И они ещё и меняются от Спринта к Спринту?

Мы обречены?)

Вы - нет, а ваш Скрам - скорее всего, увы :)

Процесс изменений в работающем ПО для вывода нового продукта - интересная штука д

Сюжет сгущается. Можете просто перечислить, кто у вас в команде по ролям. Я не понимаю, что это за "инженеры, которые не в команде". Девопс? Разрабы? Тестеры? И кто этот Лид и чего он лид. Вы извините, но очень запутанно описали кейс

Павел, это команда маркетинга, насколько я поняла. Иначе зачем разрабам верстальщик...

Да я всякие конфигурации видел, поэтому хочется уточнить. Маркетинговые команды из моего опыта вообще лучше по Канбан/Скрамбан работают, так как у них много изменений объема спринта обычно

Добавление маркетоида в одну команду с разрабами творит чудеса :)

Можно и так если Деливери + Дискавери. Но мне кажется у коллеги какойто другой кейс

Не сталкивались с продуктами вне трактовки "Программное обеспечение"?

А в Скраме все разрабы.

Смело) можно на вас ссылаться?)

Разрабы в айтишном смысле или в плане того, что все участвуют в процессе разработки?

https://t.me/agile_ru/249951