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

Question

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

С учетом этого ... Я работаю в компании по разработке веб-сайтов, которая управляет несколькими проектами за один раз, с шестью членами команды, которые составляют «производственную команду».

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

подход 2: 1 спринт за проект, переключаясь проекты

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

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

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

подхода 4: рекомендуются - Serialized работа

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

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

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

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

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

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

Answer 10

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

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

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

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