А если есть неопределенность со стороны заказчика/бизнеса/требований?

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

Придётся глубже капнуть.. Разработчик - не равно программист. В Scrum все члены dev team разработчики, то есть "участники разработки" - и те кто программирует и те кто нет. Кроссфункциональность команды означает наличие всех необходимых и достаточных компетенций для переваривания PBI

СМ это просто роль. Он у нас, у всех команд назначен.

Это не просто роль, это ключевая роль на том этапе развития где вы находитесь. Осмелюсь предположить что роль СМ у вас совмещается с другой (основной). Кстати, с какой? Без обид, но судя по вопросам у вас там непаханное поле для изменений. И либо бы коуча раньше времени выгнали либо таки он и правда недобросовестно выполнил свою работу и бросил вас на середине пути. В любом случае кто-то должен подхватить флаг.. Или отказаться от Scrum - тоже вариант =)

компетенций у команды в целом или у каждого члена команды в частности?!

Похоже в бэклоге лежит задача "получить пару советов" и надо скорее перевести ее в статус Done )

СМ один из членов команды согласно скрамгайду

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

компетенций у команды в целом или у каждого члена команды в частности?!

Вот да. Один из холиварных вопросов вокруг скрама. Задумайтесь: если человек - универсал.. Зачем ему вообще команда? И если универсалов несколько в одной команде - либо они работают каждый над своей задачей, делая полный цикл самостоятельно (что умаляет само значение работы в команде), либо все-таки делают одну задачу вместе, разделяя ее на части (что умаляет универсальность каждого). В ходе таких рассуждений, приходим к выводу, что кросс-функциональная команда - это набор специалистов с разными компетенциями, необходимыми для выполнения общего дела, а не набор универсалов, где каждый может заменить другого.

Кроссфункциональной команда должна быть, а не отдельные разработчики

Это зависит от домена. Поверьте, в инвест-банкинге это просто невозможно. Я проходил множество курсов длительностью в несколько недель, что что-то понимать в трейдинге. Тем не менее у меня не было и близко понимания близкого к пониманию кванта, например, или аналитика. И тестирование нужно тщательно, там были даже тест-архитекторы. Разработчики просто не обладают такой квалификацией

что разрабатывают эти разработчики в таком случае если они не понимают нихрена?

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

инновации идут от разработчиков

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

с такой иерархией кроссфункциональные команды мимо, а поэтому большинство агиль фреймворков тоже

Ну там конечно дураки работают =) Предложите как научить разработчиков финансам на уровне PhD, инетресно послушать

если у вас есть эксперты которые дают вам решение

Не верно. Вы себе нарисовали стереотипичную картину, что разработчики овощи-кодеры, за которых все решают. В инвест-банкинге работают умнейшее инженеры, с которыми мне довелось иметь дело. Техническая сложность систем запредельная. Да, разработчик может не шарит в деревитаивах и эконометрике, но перед ним зачастую стоит задача реализация высокопроизводительных low-latency систем, которые работают на sub millisecond (а иногда microsecond) уровне. Тут как раз Agile фреймворки делают свое дело.

Денис, я пока не понял, почему в вашем случае кросс-функциональные команды не вариант.

Это зависит от домена. Поверьте, в инвест-банкинге это просто невозможно. Я проходил множество курсов длительностью в несколько недель, что что-то понимать в трейдинге. Тем не менее у меня не было и близко понимания близкого к пониманию кванта, например, или аналитика. И тестирование нужно тщательно, там были даже тест-архитекторы. Разработчики просто не обладают такой квалификацией

Денис, я пока не понял, почему в вашем случае кросс-функциональные команды не вариант.

Потому, что практически очень сложно быть одновременно экспертом в разработке low-latency на C++, профи в эконометрике, знать бизнес процессы и иметь представление о работе смежных систем (наша система помнится на высоком уровне выглядела как 2 на 2 метра диаграмма на стене из мелких прямоугольников).

так что они делают? для высокопроизводительных систем всегда есть хорошие практики.

Не понял как это противоречит кросс-функциональным командам

Ну да, нельзя быть одновременно крутым во всем. В кросс-функциональных командах чаще бывает Т-образное распределение компетенции

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

Архитектура ПО - это wicked problem, процесс довольно творческий с высокой долей неопределенности и не сводится к набору хорших практик

т.е одна команда архитектурная и техническая

Нет, разве я это говорил? Аналитики кванты, разработчики и тестировщики были в одной команде

А в чём холиварность? Кроссфункциональная должна быть команда, но это не означает, что все в команде должны быть кроссфункциональными.

Вот в этом и есть спорный момент. В том, что некоторые трактуют кросс-функциональную команду как набор людей, где КАЖДЫЙ член команды обладает ВСЕМИ компетенциями для выполнения задачи. Ибо в скрам гайде неоднозначная формулировка.

там все очень однозначно