Как работает Scrum, когда у вас есть несколько проектов?
Я довольно хорошо прочитал о преимуществах и процессах Scrum. Я получаю идеи о незавершенных работах, графиках полного цикла, итерациях, использовании пользовательских историй и других различных концепциях Scrum-среды.
С учетом сказанного... Я работаю в фирме по веб-разработке, которая управляет несколькими проектами одновременно, с шестью членами команды, которые составляют "производственную команду".
Как Scrum работает с несколькими проектами? Вы все еще только планируете итерацию для одного проекта в определенное время, и вся команда работает над ним, и затем вы переходите к следующему проекту с новой итерацией, когда эта итерация завершена? Или существует ли "гибкий" способ управления несколькими проектами с их собственными итерациями только с одной командой одновременно?
10 ответов
Scrum на самом деле не требует, чтобы вы работали над отдельным продуктом. В нем просто говорится, что есть куча вещей, которые необходимо сделать (отставание продукта), определенное количество времени, доступное на следующей итерации (полученное из скорости проекта), и есть элементы, выбранные клиентом /business как наиболее приоритетный из этого пула проблем / задач, которые будут выполнены на следующей итерации (отставание спринта).
Нет никаких причин, по которым резервы продукта и спринта должны быть из одного проекта - даже в одном проекте будут отдельные единицы работы, которые похожи на отдельные проекты - пользовательский интерфейс, бизнес-уровень, схема базы данных и т. Д. В частности, разработка корпоративного программного обеспечения происходит таким образом, когда у вас есть ряд кодовых баз, которые все должны развиваться. Процесс Scrum - встречи, вопросы, график сгорания и т. Д. - все работает, будь то один проект или несколько.
Сказав это, на практике для каждой итерации часто полезно иметь основную тему - "создать модуль отчетности" или "интерфейс с API системы XYZ" - чтобы многие проблемы возникали из одного проекта или области и В конце итерации вы можете указать на большую часть работы и поставить галочку напротив нее.
Я думаю, что ответ зависит от того, "кто будет приоритезировать элементы отставания" (то есть решить, что нужно сделать в первую очередь). Если это один человек, то этот человек является владельцем продукта для ваших проектов, и вы можете иметь единый журнал невыполненных работ для всех элементов для всех проектов - или список заданий для каждого проекта - и вы выбираете элементы из всех проектов, когда вы планируете Спринт. В этом случае Scrum "работает" нормально.
Если у каждого проекта есть своя ответственность, то вы, вероятно, столкнетесь с некоторыми проблемами, когда каждый ответственный - более или менее осознанно - попытается поддержать свой проект (ы). ИМХО, вам нужно иметь одного Владельца продукта только с полномочиями урегулировать приоритеты арбитражем.
Одно из правил, которое следует соблюдать в таком контексте, - это никогда не изменять содержимое Sprint во время Sprint. При необходимости вы можете сократить итерацию до двух или трех недель, чтобы снизить риск добавления срочного элемента в текущий спринт.
Я должен не согласиться. Я думаю, что ключевым моментом в этом процессе является то, чтобы команда сосредоточилась на одном проекте во время спринта. Если у вас есть специалисты, которые не могут внести свой вклад в весь процесс разработки (авторы контента, специалисты по графике, аналитики бизнес-процессов и т. Д.), Я бы исключил их из группы, когда они больше не могут вносить свой вклад. Или еще лучше, обучите их различным задачам, чтобы они могли внести свой вклад в такие вещи, как тестирование.
Следует также помнить, что параллельная работа над проектами убивает ваш график. Подумайте об этом: для простоты, скажем, у нас есть 5 проектов, использующих одну команду и начинающих в одну и ту же дату. Каждому проекту требуется 3 месяца работы. В лучшем случае, если вы работаете параллельно, вы закончите все сразу, и это займет 15 месяцев. Ваша скорость будет снижена, потому что вы можете уместить только 1/5 месяца усилий в одном спринте. Вы также будете проводить 5 демонстрационных встреч одновременно. Так что в лучшем случае вы реализуете свои 5 проектов за 15 месяцев, и ваши конкуренты будут утверждать, что они могут выполнить ту же самую работу в 3. Ваши команды, оценивающие зрелость, пострадают, потому что они смогут учитывать только 20% своего доступного труда. Вы можете обнаружить, что на самом деле вы не можете выполнить некоторые задачи в одном спринте. Если вам нужно изменить количество проектов, которые вы работаете, с 5, ваша команда должна будет скорректировать свои оценочные привычки, которые повредят эффективности команд. Кроме того, вашей команде будет сложно самоорганизоваться, когда для простого переназначения задачи может потребоваться развернуть новую среду разработки до начала работы.
Если бы вы запускали одни и те же 5 проектов поочередно, вы бы выполнили 5-й проект за те же 15 месяцев, но вы бы проинформировали своего клиента, что ваша команда так востребована, что у вас есть 12-месячное отставание и вы можете использовать то время, чтобы уточнить цели вашего проекта. Или, если у вас постоянное отставание, вы знаете, что пришло время нанять другую команду. Тем не менее, ваш лучший проект будет завершен за 3 месяца с клиентом, который быстро улучшился в течение активного периода. Вы можете закончить этот проект годом ранее и можете добавить его в свое резюме. Ваша скорость спринта стабилизируется в течение этого периода времени, и вы можете обнаружить, что он достигает своего шага после одного или двух проектов и способен достичь большего в данном спринте.
Я думаю, что запуск проектов поочередно является одним из самых больших препятствий для организации, пытающейся принять разборки. Это серьезное культурное изменение, связанное с деконструкцией роли менеджера проекта, но выгоды от этого процесса огромны.
Имейте в виду, что ВСЕМ не обязательно быть полноправным членом команды. Они могут вовлекать вашего клиента в зал ожидания, готовиться к процессу разработки. Я оставляю своих бизнес-аналитиков, сетевых архитекторов и специалистов по графическому дизайну экспертами в предметной области и присоединяю их к команде только по мере необходимости. Пусть они работают со спринтом 0. Вы будете удивлены, насколько увлекательна работа над внешним видом и рабочим процессом. Также хорошо подготовить своего клиента к пониманию того, что, когда развитие начинается всерьез, уровень его участия может фактически возрасти и что для него важно быть доступным. Дайте им знать расписание, чтобы у них было достаточно времени, чтобы заранее позаботиться о таких вещах, как отпуск и каникулы.
Я был в этой точной ситуации.
Если у вас есть один владелец продукта в проектах, то Филипп абсолютно прав; Один спринт с одной командой должен работать просто отлично.
Если у вас более одного владельца продукта, то в идеале бизнес-сторона должна выбрать одного "приоритета", на которого возложена ответственность за планирование работы. Это определенно лучшее решение.
Если (как, вероятно, имеет место) бизнес не хочет менять способ расстановки приоритетов (это было бы слишком удобно), вы можете разделить команду и запустить два одновременных спринта. Однако с командой из шести человек я бы не разделил ее на более чем 3 команды (я бы не хотел делить это вообще, но я думаю, что 2-3 команды были бы работоспособны). Делить дальше, как предполагает Кенни, и иметь команды из одного человека, мне кажется несколько бессмысленным, так как тогда у вас больше нет команды, только отдельные программисты.
Если вы разделяете команду, я не вижу особой ценности в объединении стоячих мест, если только у вас нет отдельных спринтов, работающих над одной и той же кодовой базой, но тогда это может быть аргументом для объединения этих команд с целью спринт
Я думаю, что Anopres был прав: лучший способ - избежать нескольких проектов одновременно с Scrum. Сделайте все, чтобы убедить, что слишком много параллельного запуска неэффективно.
Давайте предположим, что 5 проектов каждый около 3 месяцев для команды из 5 человек.
Подход 1: каждый человек работает над одним проектом в команде
- 1/5 скорости доставки за проект дает 15 месяцев доставки для всех проектов
- Каждый человек эксперт, но только в своем проекте
- Нет командного духа
Подход 2: 1 спринт на проект, переключение проектов
- Каждый шестой спринт работает над проектом
- Слишком длительный промежуток времени между работой над проектом - нерегулярное добавочное значение для проекта (для отложенного продукта да), легко забываемое, усилия, необходимые для восстановления контекста
- Первый проект сдан примерно через 12-13 месяцев (при условии 2-недельного спринта)
Подход 3: 5 проектов в одном спринте
- Требует слишком подробного разделения задач, чтобы вписаться в спринт
- Очень небольшая добавочная сборка для каждого проекта
- Поставка первого проекта примерно через 12-15 месяцев
Подход 4: рекомендуется - Сериализованная работа
- Команда работает над одним проектом за проектом
- Первый проект запущен и сдан через 3 месяца
- Второй проект начался после 3-го месяца, сдан после 6-го месяца
- ...
- 5-й проект начался после 12-го месяца, сдан после 15-го месяца
- Команда сосредоточена на проекте, интенсивных исследованиях и сотрудничестве с заказчиком
- Вся команда в целом хорошо знает все проекты
- Не тратьте время на переключение контекста
- Требуется хорошее командное сотрудничество (конфликты могут замедлить доставку).
Как видите, решение 4, как правило, лучше, потому что проекты выполняются намного быстрее, команда работает вместе и эффективна. Другие подходы включают в себя бесполезную трату времени на переключение контекста, отсутствие полной совместной работы команды, очень длительное время выполнения всех проектов и т. Д.
А как насчет ухода за отставанием? Если команда работает сразу над одним проектом, это просто - все присоединятся. Если есть несколько проектов, нам, возможно, придется делегировать отдельных людей на отдельные сеансы груминга (задействована не полная команда).
Важно убедить клиентов, что запуск второго проекта через 3 месяца все равно приведет к более быстрой доставке (через 6 месяцев), а не к немедленному запуску его со всеми остальными. Это иллюзия, что менеджеры видят - мы начинаем 5 проектов сразу, мы упорно работаем и доставить понемногу. В конце концов, это не эффективно, однако.
Вот почему я не верю, что scrum эффективен для нескольких параллельных проектов, очень сложно сопоставить его с фреймворком и работать в соответствии с правилами scrum. Иногда может быть хорошо иметь 2 проекта, чтобы держать всех людей занятыми, но чем больше проектов мы добавим, тем менее эффективными будут схватки. Может быть, канбан - это альтернатива просто для того, чтобы увидеть прогресс и командную работу (не такую сильную, как в команде Scrum)?
С уважением, Адам
В последнее время я читал еще одно мнение, а именно, что в гибкой среде концепция проекта может быть контрпродуктивной и может быть устранена. Согласно этой точке зрения, организация должна сосредоточиться на релизах. Это потому, что проекты - это искусственные блоки работы, которые не приносят никакой пользы, пока не будут завершены. Они противоречат цели Agile по частичной доставке стоимости. Релиз более соответствует Agile, потому что он ориентирован на обеспечение ценности, а также потому, что его область действия может быть уменьшена или расширена в зависимости от того, что команды могут предоставить до следующего Релиза.
Существует потенциальная золотая середина, в которой то, что раньше называлось Проектом в вашей компании, теперь переупаковывается как общая Agile Theme или Feature. Преимущество этого подхода заключается в том, что тема или функция теперь могут быть реализованы в единицах стоимости, если владелец продукта сочтет это целесообразным.
До сих пор существует вопрос о том, чтобы одна команда работала над несколькими Продуктами, и это вопрос из-за законных опасений по поводу знаний в области и возможных технических навыков. Но продукты, созданные с помощью Agile, даже несколько продуктов, созданных одной командой, постоянно накапливают выпускную стоимость. Проекты, напротив, ничего не стоят, пока не закончат (и многие этого не делают).
Что-то думать о...
Члены команды могут распределять свое время между scrum-проектами, но гораздо эффективнее полностью посвятить членов команды. Члены команды также могут переходить от одного спринта к другому, но это также снижает производительность команды. Проекты с более крупными командами организованы в виде нескольких этапов, каждый из которых ориентирован на различные аспекты разработки продукта при тесной координации их усилий.
Как сказал @Chris, у нормального проекта есть подпроекты внутри. У вас есть только одно отставание.
Думайте в отставании со всеми вашими проектами. Первая проблема: вы назначаете приоритеты задачам или проектам? Я предпочитаю отставание от проекта. По крайней мере, иметь четкие приоритеты, которые есть у владельца продукта.
Наличие разных владельцев продуктов и в связи с тем, что эти владельцы продуктов не собираются договариваться о том, сколько времени они должны уделять каждому проекту. "Кто-то" должен будет принять решение о том, как управлять межпроектными приоритетами. Примечание: разработчики не должны этого делать.
Это наш менеджер проекта "S", который уравновесит ресурсы, необходимые владельцам продукта, и время, которое могут дать члены команды. Владелец продукта A заплатил за один месяц работы, но владелец продукта B всегда обновляет свой проект (и платит вам тоже хорошо). Есть кое-что, как вы уравновесите свою команду, чтобы у А был его один месяц (время разработчика), и не мешали Б заполнять ваши карманы.
В случае внутреннего программного обеспечения (одна компания, тысяча проектов). Владельцы различных продуктов должны согласовать время, отведенное им. Они живут не изолированно, а в той же лодке, что и вы (менеджер проекта "С"). Они сделают вашу жизнь проще, если вы сможете отложить некоторые задачи, но в то же время вы никогда не должны забывать об их потребностях.
Ну, я все еще пытаюсь найти лучший способ сделать это. Но это то, что мы настаиваем прямо сейчас. Я надеюсь, что это помогает.
Я хотел бы внести свой вклад. Вот как я это делаю:
- В каждой команде есть один владелец продукта и один продукт. Владельцем продукта не обязательно должен быть один человек, но эта "сущность" владельца продукта отвечает за невыполненную работу продукта.
- Журнал ожидания продукта содержит пользовательские истории каждого проекта (все проекты здесь). У каждого пользовательского рассказа есть свои усилия / исторические баллы (ответственность команды) и бизнес-ценность (ответственность владельца продукта).
- У нас есть "уход за продуктом", встречающий каждый спринт. Перед этой встречей владелец продукта обновил деловые ценности историй (если они нуждаются в каких-то изменениях по какой-либо деловой причине - нам это не нужно и не должно волновать) и включил несколько новых историй. На этой встрече объясняются новые истории, а также обновляются усилия. Эта встреча длится около часа (кроме первого раза, около 4 часов).
- Когда мы собираемся планировать новый спринт, мы открываем журнал ожидания продукта, заказываем истории по ROI (это ценность для бизнеса) и планируем истории до тех пор, пока не пройдет время.
И это все. Я могу сказать, что это работает довольно хорошо. Для этого мы используем несколько таблиц Google (журналы продуктов и журналов спринтов, как с диаграммами и прочим), так и Redmine (с определенной семантикой) для онлайн-организации каждый день: время, ход выполнения задач и т. Д.
Проблема с этим подходом заключается в том, что у меня есть дубликаты задач в электронной таблице журнала спринта и Redmine. Но я не нахожу онлайн-инструмент для этого полностью онлайн. Я скучаю по бэклогу продукта в redmine (для меня нет других семантических работ), одной доске в jira, больше историй в тайге и так далее.
Я бы предложил запустить один спринт для каждого проекта и провести 1 ежедневное совещание в режиме ожидания для обработки всех активных источников / проектов.