Как разделить разработчиков между несколькими гибкими проектами?

  1. 5 продуктов на 4 платформах
  2. ~100 реализованных проектов на разных стадиях(Где проект это набор продуктов, настроенных под заказчика.)
  3. 15 разработчиков + 5 QA
  4. Рой небольших четких заданий/CR's/Stories размером от 8 до 100 часов, которые легко оценить, поскольку они просты и более или менее похожи.
  5. Приток новых историй для проекта и продукта непредсказуем

Что лучше всего подходит для такой ситуации. Я намеренно опускаю свое решение для поиска альтернативного решения.

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

Ответы (2)

TL;DR

Как разделить разработчиков между несколькими гибкими проектами?

Вы не знаете. Это по своей сути не является гибким.

Это попахивает проблемой X/Y, где X ( настоящая проблема), скорее всего, будет исполнительным поручением «делать больше с меньшими затратами» без приоритизации проектов, основанных как на бизнес-ценности, так и на ограниченности ресурсов. Однако вы или ваша организация, возможно, решили решить для Y, ища серебряную пулю, которая сделает невозможное возможным.

Серебряной пули не существует. Убедитесь, что вы решаете для X, а не для Y!

Ваши общие параметры

В гибкой практике вы обычно можете выбирать между:

  1. Фиксированные кросс-функциональные команды, которые работают над разными проектами, но только по одному.
  2. Команды, основанные на продукте, где команды формируются вокруг каждого продукта. Обратите внимание, что у каждого продукта будет свой отдельный Бэклог Продукта, и каждая команда будет работать только с одним Бэклогом Продукта.
  3. Команды, основанные на функциях, где команды формируются вокруг функций (а не проектов), которые могут либо совместно использовать один бэклог продукта, либо иметь один бэклог на каждую фиче-команду.

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

Вы должны учитывать ограничения ресурсов.

Во всех случаях вы не можете делать то, что, кажется, пытаетесь сделать, а именно размазывать арахисовое масло еще тоньше, не регулируя ограничения ресурсов. Конкретно:

  1. 20 членов команды недостаточно для поддержки 100 одновременных проектов. Одна команда, один проект! является жестким правилом для всех гибких фреймворков.
  2. Если вы не справились с абстрагированием своей архитектуры или созданием кросс-функциональных команд лучше, чем вы описали здесь, у вас не пять продуктов, а двадцать! Как правило, 5 products * 4 platforms = 20 product backlogs.
    • Для этого потребуется как минимум 20 команд, если только вы не определите приоритеты и последовательность результатов.
    • Вы также можете рассмотреть возможность создания кросс-функциональных команд, которые могут создать один продукт из одного бэклога, ориентированного на несколько платформ (например, PhoneGap), но у вас по-прежнему недостаточно людей для пяти таких команд.

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

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

CodeGnome дает отличный ответ, и он на 100% прав, а вы нет.

Инструмент номер 1, который я использовал, чтобы объяснить руководству почему, — это десятиминутное упражнение, для которого не нужны ничего, кроме чистого листа бумаги и ручки. Я называю это «Многозадачная игра с буквами», уверен, что у нее есть и другие названия.

Играть:

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

Теперь у вас есть шесть коробок, три маленьких сверху и три длинных снизу. 4. Обозначьте квадратики «1», «А» и «I» (римская цифра 1). 5. Объясните упражнение.

«Ваша задача состоит в том, чтобы создавать символы. Каждый столбец представляет собой отдельный продукт: числа, буквы и римские цифры. Каждый продукт состоит из первых десяти символов в последовательности, AJ, 1-10 и римских цифр 1-X».

  1. Объясните первый раунд:

«В первом раунде мы хотим убедиться, что работаем над всем, чтобы все было сделано как можно быстрее. Итак, вы будете работать слева направо, записывая «А», затем «1», затем римскую цифру 1, прежде чем идти. чтобы сделать «B», «2» и римскую цифру 2. Когда вы закончите всю страницу, пожалуйста, поднимите руку.

  1. Приготовив секундомер, скажите им начать. Начать тайминг. Когда первый человек поднимет руку, нажмите на таймер круга. Когда большая часть зала поднимет руки, остановите таймер.

    Обычно первый человек заканчивает примерно через 25-30 секунд, а все заканчивают до истечения 40 секунд.

  2. Запишите результаты на видном месте.

  3. Объясните правила второго раунда.

    «На этот раз мы хотим сосредоточиться на одном продукте за раз. Итак, начните с выполнения от A до J, затем перейдите к числам, а затем к цифрам.

  4. Расположитесь так, чтобы вы могли легко видеть страницы нескольких участников. Приготовив секундомер, скажите им, чтобы они начали.

  5. Просканируйте участников и, как только вы увидите, что кто-то движется к колонке с номером, нажмите на таймер круга. Когда большая часть комнаты будет готова, остановите таймер.

    Как правило, первый человек закончит первую колонку за 4-6 секунд, а вся комната будет сделана менее чем за 30 секунд. Общее время второго раунда почти всегда будет меньше, чем время, которое потребовалось самому быстрому игроку в первом раунде.

  6. Запишите результаты и подумайте, что происходит, когда вы сосредотачиваетесь только на чем-то одном.

Интересная игра, но ничего общего с ситуацией, когда спрос на продукт и проект непредсказуем.
Александр- Ваш первый номер не имеет ничего общего с работой или проектами. Независимо от того, выполняете ли вы многозадачность в проектах, пользовательских историях или задачах, это вызовет проблемы. Глядя на ваш ответ на CodeGnome, кажется, что вы могли бы извлечь выгоду из рабочего процесса Kanban вместо Scrum. В любом случае вам все равно нужно заставить людей учиться сосредотачиваться на одном «элементе» за раз, будь то проект, история или задача.
Проблем с приоритетами нет, так как одна приоритетная система поддерживается во всем портфеле. Разработчики всегда работают над одной проблемой за раз на основе основных приоритетов, которые обсуждаются на основе ожиданий и ценности клиентов. Да, есть канбан-доска, но проблема в том, что она либо слишком велика, чтобы ее можно было наблюдать, либо ее нельзя фильтровать, чтобы увидеть вид конвейера доставки с вертолета. Еще одна проблема здесь, поскольку приоритеты меняются, поэтому время выполнения заказа не является надежным показателем. Мы также можем работать с довольно точной недельной/месячной скоростью, так как после этапа контроля качества есть компакт-диск с прод-билдом. И большинство вопросов являются независимыми.