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