Как SCRUM управляет средой, в которой члены команды являются общими?

13

Ну, вопросы сказали сами. На моем рабочем месте такие случаи случаются, но многие книги Agile способствуют работе на одном рабочем месте и концентрируются в текущем проекте, чтобы ускорить темпы работы.

Может быть, я не настолько осведомлен о теме, может быть, не настолько строг, но именно поэтому я хотел знать, что предлагает Agile в подобных случаях.

Кто-нибудь?

Xanathos
источник
1
Что вы имеете в виду под общим? Вы имеете в виду, что кто-то может переходить из одной команды в другую или кто-то может работать в нескольких командах одновременно? Это повлияет на мой ответ.
PDR

Ответы:

6

В методологии Scrum это просто влияет на оценку.

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

Итак, если я работаю над проектом A и проектом B в равной степени, проект A будет рассчитывать ресурсы следующим образом:

Проект A - Фактор сосредоточения команды 70%
Сам - 10 дней, 100% распределение (7 после фактора фокуса)
Джо - 10 дней, 100% распределение (7 после фактора фокуса)
Я - 10 дней, 50% распределения (3,5 после фактора фокуса) )
Итого: 25 дней * 70% коэффициент фокусировки = 17,5 прогнозируемой скорости

Вы также можете рассчитать коэффициент фокуса отдельно для членов команды, работающей полный рабочий день, и для членов команды, работающей неполный рабочий день, а не один раз для всей команды из-за снижения эффективности разделения проектов. В этом случае вы использовали бы коэффициент фокусировки моего проекта, равный 50%, и умножили бы его на персональное выделение 50% для прогнозируемой скорости на 25% или 2,5 дня .

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

Николь
источник
2
Моя проблема с этим заключается в том, что он не учитывает переключение задач. Например, рассмотрим 2-недельный (10-дневный) спринт. Наличие разработчика с коэффициентом фокусировки 50%, при котором вы получаете его / ее в течение 5 дней подряд, сильно отличается от наличия разработчика каждые два часа в течение 10 дней. Первый гораздо продуктивнее. Крайний пример, но вы поняли мою точку зрения.
Брук
@Brook Вы просто говорите о факторе фокуса (1 измерение на человека), который отличается от распределения проекта (в данном случае разделение 50/50). Фактор фокуса - это% идеального дня, который стоит вашего фактического дня . Обычно это около 70-80%, но для тех, кто разделяет проекты, это будет, вероятно, меньше (о чем я говорил в ответе). Это зависит от некоторой последовательности с течением времени. Если у вас не может быть последовательности, вы действительно не должны делать Scrum.
Николь
часть последовательности была действительно моей точкой. Если у вас есть команда, в которой постоянно тянутся люди в 10 разных направлениях, и вы не можете это изменить, Scrum вам не поможет.
Брук
@ Брук - это хороший момент, и вы помогли мне подумать об этом так, как я не думал изначально. Похоже, мы согласны.
Николь
1
@NickC Это кажется правдоподобным. По крайней мере, я уверен, что члены команды могут меняться каждый раз, к счастью, этого не так много. Рабочее место всегда остается одним и тем же, просто время, отводимое проекту, иногда вдвое меньше, чем у члена команды (потому что член команды выполняет задачи из 2 разных проектов). Но это кажется правильным для расчета скорости для различных проектов, по крайней мере. Спасибо за ссылку.
Ксанатос
10

По моему опыту в Scrum, скорость можно предсказать, только если проект и команда останутся такими же и преданными. Если что-то из этого изменится, вы не сможете использовать расчеты скорости из предыдущих спринтов для оценки. Вы можете попробовать, но вы получите гораздо больше, чем обычно.

В общем, вам определенно следует постараться сохранить команду одинаковой и преданной на МЕНЬШЕ на протяжении спринта, больше, если сможете.

ручей
источник
2
Да, в самом деле! Попытка разделить участников между проектами просто приводит к задержке всех вовлеченных проектов. Нет смысла расщеплять таких людей и думать, что все закончится быстрее.
Мартин Уикман,
+1 для здравого смысла, Вы просто не можете назначить трех женщин на беременность, чтобы сделать это через три месяца. Имеет больше смысла посвящать людей определенной задаче.
maple_shaft
Я считаю, что это «основной столп» Scrum, на самом деле. Постер, кажется, смешивает контекст, когда спрашивает «что Agile говорит в этой ситуации» (против Scrum) Есть ли ответ Agile (не Scrum) ...
Аль Биглан
1

На мой взгляд, это очень плохо скажется на всех проектах. Это не только вопрос оценки или планирования. Да, вы можете сказать, что если члены команды распределены по трем проектам и у них есть 33% от каждого проекта, вы знаете все, что вам нужно, и вы сделали, но это не так.

Переключение контекста очень дорого. Также невозможно поддерживать полную приверженность нескольким параллельным проектам, поэтому эти 33% времени разработчика далеки от 33%, когда разработчику назначен только один проект.

Другое место, где это полностью терпит неудачу - это общение. Что произойдет, если член команды, работающий в настоящее время над проектом А, должен что-то сообщить сотруднику, работавшему вчера над проектом А, но в настоящее время работающему над проектом Б? Это является препятствием для них обоих, потому что первый нуждается в информации, а второй сконцентрирован на совершенно другом проекте, и любой вопрос для проекта А просто беспокоит его. Скрам-мастер из проекта А хочет, чтобы его разработчик получал информацию как можно быстрее, а Скрам-мастер из проекта Б не хочет, чтобы член его команды беспокоился из-за чего-либо, не связанного с проектом В. Если вы хотите избежать этого, вы должны спланировать все Разработчики из команды работают над одним и тем же проектом в одни и те же дни - это большое усложнение всего процесса планирования и чего следует полностью избегать.

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

Как вывод, Agile также касается сокращения отходов (да, это из-за подхода Lean), и разделение членов команды между командами является одной из худших неудач с точки зрения введения отходов и снижения производительности. Я предполагаю, что стоимость доставленного бизнеса для 33% распределения в одном проекте будет равна стоимости бизнеса, полученной от 10-16% от полной занятости. Это означает, что разработчик не только будет участвовать в проекте в 1/3 раза, но и за это время его производительность будет между 1/3 и 1/2.

Ладислав Мрнка
источник
1

SCRUM основан на приверженной команде без общих участников, поэтому вы можете также спросить:

Учитывая, что нам сказали, что мы должны сделать истину == ложью, как нам сделать х

Если это не SCRUM, не называйте это SCRUM!

Ян
источник
0

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

Часто с персоналом, который работает на проекте только неполный рабочий день, они привлекаются только для ограниченного объема обязательств. Например, у вас может быть человек, который занимается только оптимизацией базы данных.

В этом случае часто лучше рассматривать этого человека как «ресурс», а не как члена команды. Команда решает, сколько из этого ресурса они захотят в конкретном Спринте, и дает им очень специфический набор задач, которые необходимо выполнить для Спринта. Иногда лучше, если в группе есть конкретный член команды, ответственный за этот ресурс, и они будут делать обновления статуса и отчеты о препятствиях для этого ресурса в ежедневной Scrum.

Дейв
источник
0

Я считаю, что одним из основных аспектов Scrum является сосредоточение команды на чем-то одном (один проект, одна история, одна задача ...)

Вы спросили «что предлагает Agile» в ситуации, когда вы не можете выделить ресурсы для одного проекта ... Вы можете попробовать один из:

  • Держите большую доску Канбан, которая охватывает несколько проектов. Поскольку у проекта есть потребность, он добавляется в правление, поскольку у людей есть потенциал, они вынимают ключевые истории. Проблема в том, что все проекты управляются вместе, что снижает общую предсказуемость для любого проекта. Тем не менее, отдельные элементы истории / Канбан будут извлечены и разработаны целенаправленным человеком или командой. (Вы можете попробовать создать более мелкие команды из 4-5 человек, чтобы вытащить их с доски Канбан
  • Назначайте только выделенные ресурсы. Держите пул выделенных ресурсов для проекта. Они защищены как команда, и прерывания сохраняются вблизи нуля. Также ведите «группу быстрого реагирования», которая не имеет отставания и не ориентирована на проект / продукт. Когда возникают перерывы, группа быстрого реагирования занимается перерывами. Когда у них нет прерываний, они могут сосредоточиться на улучшении системы сборки, добавлении в среду тестирования автоматизации и т. Д. Кроме того, они могут помочь с обзорами кода / обзорами дизайна и устранением сложных / неприятных ошибок, которые возникают. Управляйте разработкой так, как будто этой команды не существует. Все, что они могут сделать, это вытащить доставку. Вращайте людей через эту команду, чтобы "сохранить свежесть" (людям нравится / не нравится быть в команде быстрого реагирования ...)

надеюсь это поможет!

Аль Биглан
источник