Может ли один ресурс быть в нескольких командах для нескольких проектов?

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

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

Ответы (2)

При таком подходе возникает ряд проблем:

  • Многозадачность снижает эффективность. Каждый раз, когда им приходится переключаться между проектами, они теряют эффективность.
  • Scrum основан на идее известной производительности команды, которая используется для расчета скорости. Если члены команды меняются или выполняют работу для других команд, то скорость больше не может быть точно определена.
  • Человек фактически становится внешним ресурсом, который необходимо координировать. Это снизит эффективность команды.
  • Многие церемонии Scrum предназначены только для членов команды, работающих полный рабочий день. Например, ежедневные стендапы и ретроспективы обычно проводятся для штатных членов команды, которые преданы работе.
  • Двухкомандная роль требует расстановки приоритетов между двумя независимыми бэклогами. например, является ли для них приоритетом работа над Историей X для Команды А или Историей Y для Команды Б?
Если я могу добавить к вашему первому замечанию, некоторые исследования показали, что влияние переключения контекста на каждый проект составляет целых 20% по сравнению с первым. Поскольку часто разделяются руководители компании, это огромная цена, которую нужно заплатить, и ее следует очень открыто обсудить, прежде чем принимать решение.
Кроме того, скрам-мастеру неприятно ставить задачи. Ожидается, что команда будет самоорганизующейся в Scrum. Скрам-мастер должен очень усердно работать, чтобы уйти от практики и научить разработчиков выбирать свою работу.

У нас был богоподобный разработчик, работавший над несколькими проектами. Он был серебряной пулей для любого вопроса. Настоящий спаситель в безвыходных ситуациях. Решение здесь состояло в том, чтобы создать собственный фильтр в Jira, чтобы он мог управлять своей рабочей нагрузкой, поскольку в разных проектах использовались разные потоки и схемы. Менеджер по управлению проектами решает вопросы приоритета совместно с главным операционным директором в качестве арбитра, используя уникальные числовые приоритеты от Jira Agile. Он вообще не участвовал в Scrum-собраниях. Разработчик всегда работал над первоочередными проблемами. Его основная роль заключалась в тушении пожаров (проблемы с блокировщиками в проде) и в крайнем случае (если нам нужен бустер, чтобы закрыть все проблемы из бэклога спринта). Мы не отслеживали его личную скорость, так как у команд была разная шкала очков истории. Все баллы за решенные задачи были добавлены к скорости команды. Который' Как мы поддерживали более стабильную скорость и снижали неизвестные риски. Еще одна вещь о нем заключается в том, что, несмотря на его гораздо более высокую почасовую ставку, средняя стоимость поставленного им сюжетного очка была значительно ниже по сравнению с командами, которые он поддерживал. Так что никаких негативных последствий для бюджета не было. Надеюсь, эта история о войне была для вас полезной.

Может ли один ресурс быть в нескольких командах для нескольких проектов?
СпросиСетьПолитика конфиденциальности1y, 0v