Что лучший способ состоит в том, чтобы обработать несколько проектов, когда у Вас есть единственная группа разработчиков? [закрытый]

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

Если это полностью отдельные продукты , то при использовании Scrum я бы провел очень короткие спринты (1-2 недели) и работал над последовательностью. Итак, двухнедельный проект A, затем проект B, затем C, затем снова A - может быть, для двух спринтов, затем C и т.д. знаю хотя бы одну команду, которая так работает.

Нужны ли вам дополнительные заказы на поставку - это, скорее, функция знаний о продуктах. Может быть, вам нужен кто-то для каждого проекта, может быть, у вас есть кто-то, кто достаточно хорошо знает A, B и C, чтобы быть заказчиком.

Если продукты разные, то когда вы пытаетесь сделать это, беря разные истории из разных бэклогов, каждый спринт вы получите разделенную команду. Естественно, люди будут специализироваться на данном проекте, также будет очень сложно дать хорошее определение «готово» (готовы ли мы выпустить новые приращения для A и B, но не для C в этом спринте?). Если вы не можете упорядочить проекты с короткими спринтами, я бы посмотрел в сторону Канбана за попытку внести в это некоторую организацию.

Если это один продукт / одна кодовая база - тогда все намного проще. Даже если команде придется затрагивать разные области кодовой базы из-за разных проектов, они все равно будут работать над одними и теми же продуктами, поэтому вся механика Scrum будет хорошо применяться. Одно отставание, один заказ на поставку.

Следует отметить один недостаток в том, что люди в команде будут переключать контекст, и это влечет за собой штраф, независимо от того, какой процесс вы используете. Какой бы процесс вы ни выбрали, постарайтесь свести его к минимуму как можно дольше (до тех пор, пока бизнес сможет продержаться). Хорошая вещь в Scrum заключается в том, что он имеет встроенное соглашение с PO, что переключение контекста может происходить только на границе спринтов - другими словами, у команды будет 1-2 недели, чтобы сосредоточиться, прежде чем ей придется переключиться на другой проект.

Также не забывайте обо всех технических приемах гибкой разработки. Модульные тесты. Автоматические сборки и тесты. Проверка кода. Умное использование репозиториев. Высокие стандарты re. качественный. Все это необходимо в такой сложной обстановке.

Еще немного подробностей. Это одна большая производственная команда, которая делит между собой множество проектов? Это небольшая команда (5 человек) с большим количеством проектов?

Почему у вас много проектов? Работают ли они в разные временные рамки, причем некоторые из них являются «настоящей работой», а другие - «если вы не заняты, сделайте это в качестве фоновой задачи».

Я полагаю, что ключевым моментом здесь может быть соотношение проекта и разработчика.

У нас есть один отдел, состоящий примерно из 15 человек, который одновременно выполняет 3-4 проекта.Обычно люди участвуют в проекте в любое время, но могут перемещаться между ними по мере того, как проекты проходят разные фазы и необходимы разные навыки. В частности, тесты, похоже, часто меняют проекты.

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

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

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

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

(Кстати, у меня есть предложение по Зоне 51 именно для такого рода вещей: http://area51.stackexchange.com/proposals/9543/development-methodologies )

ИМХО, Scrum более эффективен, когда у вас есть по крайней мере 3-4 итерации по две недели с командой из 4-6 разработчиков. Так что для проектов +- 400 человек в день

Я думаю, что это плохая идея - делать несколько проектов одновременно.

Пожалуйста, проверьте также этот ранее отвеченный вопрос:

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