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

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

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

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

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

еще одна вещь, чтобы держать в имейте в виду, что параллельное выполнение проектов убивает ваше расписание. Рассмотрим это: для простоты скажем, что у нас есть 5 проектов, использующих одну и ту же команду и начинающихся в одну и ту же дату. Каждый проект требует 3 месяца усилий, в лучшем случае параллельно, вы закончите их все сразу, и это займет 15 месяцев. Ваша скорость будет получить сливки, потому что вы можете поместиться только 1/5 месяца усилий в одном спринте. Вы также будете делать 5 демо встреч одновременно. Так в лучшем случае, вы поставите свои 5 проектов за 15 месяцев, и ваш конкурент будет утверждать, что они могут сделать ту же работу за 3. Ваши команды, оценивающие зрелость, пострадают, потому что они смогут рассмотреть только 20% своей доступной рабочей силы. Вы можете обнаружить, что вы на самом деле не в состоянии выполнить некоторые задачи в одном спринте. Если вам нужно изменить количество проектов, которые работают с 5, вашей команде придется скорректировать свои привычки оценки, которые повредят эффективности команд. Кроме того, вашей команде будет трудно самоорганизоваться, когда простое переназначение задачи может потребовать создания новой среды разработки до начала работы.

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

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

имейте в виду, что каждый не должен быть полноправным членом команды. Они могут вовлекать вашего клиента в зал ожидания, готовясь к процессу разработки. Я держу своих бизнес-аналитиков, сетевых архитекторов и людей графического дизайна в качестве экспертов домена и только прикрепляю их к команде как необходимый. Пусть они работают с sprint 0. Вы будете удивлены, насколько привлекательна работа над внешним видом и рабочим процессом. Также полезно подготовить своего клиента с пониманием того, что, когда развитие начинается всерьез, уровень его участия может фактически подняться и что для него важно быть доступным. Дайте им знать расписание, чтобы у них было много времени, чтобы иметь дело с такими вещами, как отпуск и праздники заранее.

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

Если у вас есть один product owner в проектах, то Phillipe абсолютно прав; один спринт с одной командой должен работать нормально.

Если у вас есть больше чем один владелец товар, то в идеале бизнес должен выбрать один prioritizer-кто несет ответственность за планирование работы. это определенно лучшее решение.

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

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

есть еще одно мнение, о котором я читал в последнее время, а именно, что в гибкой среде концепция проект может быть контрпродуктивным и может быть устранен. Согласно этой линии мышления, организация должна сосредоточиться на выпускает вместо. Это потому что проекты искусственные коробки работы которые не производят никакое значение до тех пор пока они не закончены. Они противоречат цели Agile часто поставлять shippable значение. А релиз больше соответствует Agile, потому что он ориентирован на доставку ценности и потому что его область может быть уменьшена или расширена на основе того, что команды могут доставить до следующего релиз.

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

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

есть о чем подумать...

Я думаю, что anopres был прав: лучший способ-избежать нескольких проектов одновременно с scrum. Сделайте все, чтобы убедиться, что слишком много работать параллельно неэффективно.

предположим, что 5 проектов каждый около 3 месяцев для команды с 5 людьми.

подход 1: каждый человек работает над одним проектом в команде

• 1/5 скорость доставки в проект дает 15 месяцев доставки для всех проектов
• каждый человек является экспертом но только в собственном проекте
• нет командного духа

подход 2: 1 спринт на проект, переключение проектов

• каждый 6-й спринт работает над проектом
• слишком много времени между проектной работой - не регулярное инкрементное значение для проекта (для отставания продукта да), легко забыть, усилия, необходимые для восстановления контекста,
• первый проект доставлен примерно через 12-13 месяцев (при условии, что 2 недели спринт)

подход 3: 5 проекты в одиночном спринте

• требует слишком много подробного разделения задач, чтобы вписаться в sprint
• очень мало инкрементной сборки на проект
• поставка первого проекта После около 12-15 месяцев

подход 4: рекомендуется-Сериализованная работа

• команда работает над одним проектом после проекта
• первый проект запущен и доставлен через 3 месяца
• второй проект начался после 3-го месяц, поставленный после 6-го месяца
• ...
• 5-й проект начался после 12-го месяца, доставлен после 15-го месяца
• команда сильно сфокусированная на проекте, интенсивном исследовании и сотрудничестве с клиентом

Как сказал @Chris, обычный проект имеет подпроекты внутри. У вас только одно отставание.

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

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

вот он приходит наш менеджер проекта "S", который сбалансирует ресурсы, необходимые владельцам продуктов, и время, которое могут дать члены команды. Product owner a заплатил за один месяц работы, но product owner B всегда обновляет свой проект (и хорошо платит вам). Там некоторые, как вы будете балансировать свою команду для A, чтобы иметь его один месяц (время разработчика), и не останавливайте B от наполнения карманов.

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

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

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

Я бы предложил запустить один спринт для каждого проекта и иметь 1 ежедневное совещание standup для обработки всех активных пружин/проектов.

Я хотел бы внести свой вклад. Вот как я это делаю:--1-->

• существует один product owner и один продукт отставание в команде. Product owner не должен быть одним человеком, но этот product owner "сущность" отвечает за отставание продукта.
• отставание продукта имеет пользовательские истории каждого проекта (все проекты здесь). Каждая история пользователя имеет усилия / точки истории (ответственность команды) и бизнес-ценность (владелец продукта ответственность.)
• У нас есть" Product backlog grooming", встречающийся каждый спринт. Перед этой встречей product owner обновил бизнес-ценности историй (если они нуждаются в некоторых изменениях по какой - либо бизнес-причине-что нам все равно и не должно быть) и включил некоторые новые истории. На этой встрече объясняются новые истории, а также обновляются усилия. Эта встреча длится около часа (кроме первого раза, около 4 часов).
• когда мы собираемся планировать новый спринт мы открываем отставание продукта, заказываем истории ROI (это бизнес-ценность / усилия) и планируем истории, пока не пройдет время.

и это все. Я могу сказать, что это работает довольно хорошо. Для этого мы используем пару электронных таблиц google (отставание продукта и отставание sprint, как с диаграммами, так и с другими), а redmine (с определенной семантикой) для онлайн-организации каждый день: время, ход выполнения задач и т. д.

проблема с этим подходом это то, что у меня дублируются задачи в таблице Sprint backlog и redmine. Но я не нахожу никакого онлайн-инструмента для этого полностью онлайн. Я пропускаю отставание продукта в redmine (никаких других семантических работ для меня), одну доску в jira, больше историй в taiga и т. д.