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

91

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

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

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

Тим Найт
источник
9
Хотел бы я знать, я работаю над 3+ проектами и мне приходится делать 3+ SCRUMS в день. : cry:
Чад Грант
Этот вопрос не по теме, потому что он выходит за рамки этого сайта, как определено в разделе Какие темы я могу задать здесь? Также см. Какие типы вопросов мне следует избегать? Вы можете задать вопрос на другом сайте Stack Exchange , например, по управлению проектами или разработке программного обеспечения . Обязательно прочтите тематические страницы в Справочном центре для любого сайта, на котором вы собираетесь задать вопрос.
Макиен
3
@Makyen, здесь следует учитывать, что этому вопросу успешно 8,5 лет, и он возник задолго до того, как существовало большинство субстековых бирж. Таким образом, хотя сейчас эта тема может быть лучше всего обслужена чем-то вроде Project Management Stack Exchange, в то время вопрос о методах Scrum был невероятно актуален для разработчиков и их методологий в том, как лучше всего выполнять работу.
Тим Найт
Я согласен, это было разумно в то время, когда его спросили. В вопросе как вопросе нет ничего плохого. Это просто не по теме для SO в настоящее время. То, что актуально для SO, со временем изменилось. Хотя этот вопрос интересен программистам, он в первую очередь не касается программирования. Речь идет о процессе Scrum, который представляет собой метод управления проектами, а не конкретно программирование. Речь идет об «управлении несколькими проектами… только одной командой…», которые могут быть самыми разными типами проектов. Таким образом, уместно закрыть его. Я бы не стал голосовать за его удаление, так как здесь есть полезная информация.
Макиен
2
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что он касается организационных практик, а не программирования.
Кристьян

Ответы:

61

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

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

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

Крис Латта
источник
4
+1: Суть Scrum - это ежедневные встречи для координации действий. Работает над одним или несколькими проектами.
S.Lott
4
Я не согласен с С.Лоттом, я думаю, что суть в спринте, а стоячая встреча - это инструмент для управления спринтом. Я бы запустил 6 спринтов или по 1 на проект.
kenny
@Kenny: Если это несущественно, не могли бы вы обойтись без ежедневных выступлений по каждому отдельному проекту? Если да, то что вы делаете, чтобы не сбиться с пути каждого проекта?
S.Lott
1
@ S.Lott, встреча предназначена для обсуждения проблем, если они возникают. Я бы по одному за всю команду. Не помешает держать в курсе, и разные / новые точки зрения часто могут быть ценными.
kenny
А как насчет трех проектов, трех членов команды, каждый из которых разрабатывает собственный код для разных владельцев продукта? В этом случае есть 3 команды?
jolySoft
25

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

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

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

филант
источник
16

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

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

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

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

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

Anopres
источник
Это работает, только если вы МОЖЕТЕ переназначить членов команды. Если им некуда идти, нельзя оставлять их без дела.
BlueChippy
8

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

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

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

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

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

ДэнЗингерман
источник
5

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

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

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

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

Боб Либерман
источник
1
Мы согласны с тем, что мы должны минимизировать «инвентарь программного обеспечения», который представляет собой накопленную стоимость бизнеса, которую еще предстоит реализовать.
AndyM
4

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

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

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

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

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

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

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

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

Подход 4: рекомендуемый - серийная работа

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

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

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

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

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

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

Адам Кравчик
источник
3

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

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

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

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

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

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

График
источник
3

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

Бхарат Кришнамурти
источник
0

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

Кенни
источник
Кенни, так по одному спринту для каждого проекта за раз? Или вы говорите о запуске нескольких спринтов одновременно и разделении команды, как предлагают другие?
Тим Найт,
Привет, Тим, я представлял, как не менять структуру вашей команды, разбивая команды на спринты, а просто запускать отдельные спринты / бэклоги / и т. Д. Для каждого проекта. На каждом выступлении попросите каждого человека прокомментировать, что его беспокоит. Для меня было бы неплохо следить за всеми / всем или в курсе.
kenny
0

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

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

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

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

Hosseio
источник
Как сосредоточить внимание на каждом продукте в очереди? Теги, соглашение об именах и т. Д.? Я реализовал аналогичный подход, но пытался сохранить все в TFS, и еще не нашел хорошего решения, позволяющего просматривать как отставание, так и продукты для функций / историй.
BlueChippy