Как Толпа работает, когда у Вас есть несколько проектов? [закрытый]

Я думаю, что ответ зависит от" , кто будет располагать по приоритетам неудовлетворенные объекты " (т.е. решите что потребности быть сделанными сначала). Если это - единственный человек, то этот человек является Владельцем продукта для Ваших проектов, и у Вас может быть единственное отставание, будет все объекты для всех проектов - или отставание на проект - и Вы выбираете неудовлетворенные объекты из всех проектов при планировании Sprint. В этом случае, Толпа прекрасные "работы".

, Если каждый проект будет иметь свое ответственное, то Вы, вероятно, встретитесь с некоторыми проблемами, где каждое ответственное желание - более или менее сознательно - пытаются способствовать его проекту (проектам). По моему скромному мнению, у Вас должен будет быть один Владелец продукта только с полномочиями для решения приоритетов в арбитражном порядке.

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

Я был в этой точной ситуации.

, Если у Вас есть один владелец продукта через проекты тогда, Phillipe абсолютно корректен; Один спринт с одной командой должен работать просто великолепно.

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

, Если (как, вероятно, имеет место) бизнес не хочет изменяться, как они хотят расположить по приоритетам вещи (который был бы слишком удобен), тогда, можно разделить команду., и выполненный два параллельных спринта. Однако с командой шесть, я не разделил бы его на больше чем 3 команды (я не захочу разделять его вообще, но я думаю, что 2-3 команды были бы осуществимы). При разделении дальше, поскольку предлагает Kenny, и команды наличия единственного человека кажутся мне несколько бессмысленными, поскольку тогда у Вас больше нет команды, просто отдельные программисты.

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

Я предложил бы выполнить одну Sprint для каждого Проекта и имел бы 1 ежедневную стоячую встречу для обработки всего активного Спрингса/проектов.

Как сказал @Chris, у нормального проекта есть подпроекты внутри. Однако у вас есть только одно невыполненное задание.

Думайте в очереди со всеми своими проектами. Первая проблема: вы расставляете приоритеты задачам или проектам? Я предпочитаю отставание по каждому проекту. По крайней мере, чтобы иметь четкие приоритеты, которые есть у product owner-а.

Наличие разных владельцев продуктов и из-за того, что эти владельцы продуктов не собираются договариваться о том, сколько времени они должны уделять каждому проекту. «Кто-то» должен будет принять решение о том, как управлять межпроектными приоритетами. Примечание: разработчики не должны этого делать.

Вот и наш S-менеджер проекта, который уравновесит ресурсы, необходимые владельцам продукта, и время, которое могут дать члены команды. Владелец продукта A заплатил за один месяц работы, но владелец продукта B всегда обновляет свой проект (и хорошо платит вам). Вот как вы сбалансируете свою команду, чтобы у А был один месяц (время разработчика), и не мешать Б набивать вам карманы.

В случае внутреннего ПО (одна компания, тысяча проектов). Владельцы разных продуктов должны согласовать время, отведенное им. Они живут не изолированно, а в одной лодке с вами (менеджер проекта «С»). Они сделают вашу жизнь проще, если откладывают некоторые задачи, но в то же время вы никогда не должны забывать об их потребностях.

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