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

Ответ 1

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

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

Сказав это, на практике часто для каждой итерации очень важно иметь основную тему - "сделать модуль отчетности" или "интерфейс с API-интерфейсом XYZ" - так что многие проблемы возникают из одного проекта или области и в конце итерации вы можете указать на большой объем работы и поставить галочку против него.

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Если у вас есть один владелец продукта по проектам, то Филлип абсолютно прав; Один спринт с одной командой должен работать нормально.

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

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

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

Ответ 5

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

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

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

Что-то подумать...

Ответ 6

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

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

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

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

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

• Команда работает над отдельным проектом после проекта
• Первый проект запущен и отправлен через 3 месяца.
• Второй проект начался после третьего месяца, который был отправлен после 6-го месяца.
• ...
• Пятый проект начался после 12-го месяца, который был отправлен после 15-го месяца.
• Команда, ориентированная на проект, интенсивные исследования и сотрудничество с клиентами
• Вся команда имеет общие хорошие знания обо всех проектах.
• Отсутствие времени на переключение контекста
• Требуется хорошее командное сотрудничество (конфликты могут замедлить доставку).

Как видите, решение 4 обычно лучше, потому что проекты поставляются гораздо быстрее, команда работает вместе и эффективна. Другие подходы включают время отхода от переключения контекста, отсутствие полного командного сотрудничества, очень длительное общее время доставки всех проектов и т.д.

А как насчет отставания? Если команда работает над одним проектом сразу, это просто - все присоединятся. Если есть несколько проектов, нам может потребоваться делегировать отдельных людей для разделения сеансов уборки (не задействована полная команда).

Важно убедить клиентов, что запуск 2-го проекта через 3 месяца по-прежнему приведет к более быстрой доставке (после 6-го месяца), а не к немедленному началу работы со всеми остальными. Это иллюзия, которую видят менеджеры - мы начинаем сразу 5 проектов, мы много работаем и понемногу. В конечном итоге это неэффективно.

Вот почему я не верю, что схватка эффективна для нескольких проектов параллельно, очень сложно сопоставить ее с каркасом и работать в соответствии с правилами схватки. Иногда бывает хорошо, что у вас есть 2 проекта, чтобы все люди заняты, но чем больше проектов мы добавим, тем меньше эффективность схватки. Может быть, канбан - это альтернатива, чтобы увидеть прогресс и работу в команде (не так сильно, как в команде Scrum)?

С уважением, Адам

Ответ 9

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

Ответ 10

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

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

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

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