На мою думку, це вплине на всі проекти дуже погано. Справа не лише в оцінці або плануванні. Так, ви можете сказати, що якщо члени команди розподілені на три проекти, і вони мають 33% розподілу на кожен проект, ви знаєте все, що вам потрібно, і ви зробили, але це неправда.
Контекстна комутація дуже дорога. Також неможливо зберегти повну прихильність до декількох паралельних проектів, тому 33% відсотків часу розробника далеко від 33%, коли розробник призначений лише для одного проекту.
Ще одне місце, де це повністю не вдається - це спілкування. Що станеться, якщо член команди, що працює над проектом A, повинен щось спілкуватися з членом команди, який працював над проектом A вчора, але в даний час працює над проектом B? Це є перешкодою для обох, тому що першому потрібна інформація, але другий зосереджений на зовсім іншому проекті, і будь-яке питання для проекту А просто його турбує. Майстер Scrum з проекту A хоче, щоб його розробник отримував інформацію якомога швидше, а Scrum master з проекту B не хотів, щоб його члена команди заважали чим-небудь, не пов’язаним з проектом B. Якщо ви хочете цього уникнути, ви повинні спланувати все розробники з команди, які працюють над тим самим проектом протягом одних днів - це велике ускладнення для всього процесу планування і чогось, чого слід повністю уникати.
Ви також повинні планувати всі зустрічі, щоб вони не стикалися. Ви також повинні розуміти, що зустріч насправді є марною, і через це має бути мінімально необхідна кількість зустрічей, якомога коротша, щоб все одно контролювати процес. Але якщо у вас є член команди, який працює над трьома проектами, він повинен брати участь у всіх засіданнях для цих трьох проектів => втричі більше зустрічей, де розробник не має жодної ділової цінності.
Оскільки складний висновок також полягає у зниженні відходів (так, це з підходу Lean), а обмін членами команди серед команд є однією з найгірших невдач у плані впровадження відходів та зниження продуктивності. Я здогадуюсь, що доставлена вартість бізнесу для розподілу 33% для одного проекту буде дорівнює вартості бізнесу, отриманій від 10-16% від розподілу часу. Це означає, що розробник не тільки братиме участь у проекті 1/3 рази, але за цей час його продуктивність становитиме від 1/3 до 1/2.