На мой взгляд, это очень плохо скажется на всех проектах. Это не только вопрос оценки или планирования. Да, вы можете сказать, что если члены команды распределены по трем проектам и у них есть 33% от каждого проекта, вы знаете все, что вам нужно, и вы сделали, но это не так.
Переключение контекста очень дорого. Также невозможно поддерживать полную приверженность нескольким параллельным проектам, поэтому эти 33% времени разработчика далеки от 33%, когда разработчику назначен только один проект.
Другое место, где это полностью терпит неудачу - это общение. Что произойдет, если член команды, работающий в настоящее время над проектом А, должен что-то сообщить сотруднику, работавшему вчера над проектом А, но в настоящее время работающему над проектом Б? Это является препятствием для них обоих, потому что первый нуждается в информации, а второй сконцентрирован на совершенно другом проекте, и любой вопрос для проекта А просто беспокоит его. Скрам-мастер из проекта А хочет, чтобы его разработчик получал информацию как можно быстрее, а Скрам-мастер из проекта Б не хочет, чтобы член его команды беспокоился из-за чего-либо, не связанного с проектом В. Если вы хотите избежать этого, вы должны спланировать все Разработчики из команды работают над одним и тем же проектом в одни и те же дни - это большое усложнение всего процесса планирования и чего следует полностью избегать.
Вы также должны планировать все встречи, чтобы не столкнуться. Вы также должны понимать, что собрание на самом деле является бесполезным, и поэтому должно быть как можно меньше необходимого количества собраний, чтобы по-прежнему контролировать процесс. Но если у вас есть член команды, работающий над тремя проектами, он должен участвовать во всех совещаниях по этим трем проектам => в три раза больше совещаний, где разработчик не создает никакой коммерческой ценности.
Как вывод, Agile также касается сокращения отходов (да, это из-за подхода Lean), и разделение членов команды между командами является одной из худших неудач с точки зрения введения отходов и снижения производительности. Я предполагаю, что стоимость доставленного бизнеса для 33% распределения в одном проекте будет равна стоимости бизнеса, полученной от 10-16% от полной занятости. Это означает, что разработчик не только будет участвовать в проекте в 1/3 раза, но и за это время его производительность будет между 1/3 и 1/2.