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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

Я думаю, что анопрес была права:лучший способ - избегать одновременного выполнения нескольких проектов с помощью 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-го месяца
• Команда, полностью сосредоточенная на проекте, интенсивных исследованиях и сотрудничестве с заказчиком
• Вся команда обладает общими хорошими знаниями обо всех проектах
• Не тратьте время на переключение контекста
• Требуется хорошее командное сотрудничество (конфликты могут замедлить доставку).

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

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

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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