Одиночная команда разработчиков, работающая над несколькими бэклогами продуктов (Продукты)
У нас есть одна команда разработчиков (около 20 членов команды), которая в настоящее время работает над 5 продуктами с 5 владельцами продуктов (по одному на каждый продукт). Мы боремся с расстановкой приоритетов между разными продуктами и множеством встреч для одного и того же.
Ниже приведены два варианта, на которые мы смотрим:
1. Объединение продуктовых резервов в один продукт.
Таким образом, эта команда может извлекать истории из одного продукта в журнал спринта. (И больше не нужно беспокоиться о приоритетах). Но отставание одного продукта может быть слишком большим и неуправляемым.
2. Разделение команды на 5 команд для каждого продукта
Но в настоящее время это невозможно, поскольку у нас есть ресурсы, специализирующиеся на конкретной сковороде, и их необходимо распределять между продуктами.
Какие-либо предложения?
5 ответов
Я бы предложил третий вариант.
Формируйте команды вокруг продуктов, которые производят больше всего работы. Затем пусть остальные разработчики работают в командах, которые охватывают оставшиеся продукты.
Что-то вроде:
Команда 1 - Продукт 1
Команда 2 - Продукт 2
Команда 3 - Продукт 3, 4, 5
Надеюсь, это уменьшит борьбу с расстановкой приоритетов в истории (хотя не полностью устранит ее).
Самое главное, чтобы определить, что вы хотите получить от новой организационной структуры и как вы намерены измерять успех.
Получите некоторые подходящие метрики на месте, попробуйте новую структуру и посмотрите, улучшаются или ухудшаются метрики. Затем проверьте и адаптируйте свой подход.
У меня есть пара моментов, на которые следует обратить внимание: приоритеты задач вообще не являются обязанностью команды разработчиков, это то, чем руководит ПО по многим причинам, но не будем об этом говорить.
Поскольку у вас нет ни одного ПО, это трансформируется в борьбу интересов. Если между ними нет общей цели, то каждый ОО захочет, чтобы их США были выполнены КАК МОЖНО СКОРЕЕ, потому что это для них самый высокий приоритет (и это вполне понятно).
Таким образом, если вы хотите сохранить одну команду для всех этих продуктов, вам понадобится ПО, которое будет работать в качестве единой точки контакта для команды разработчиков, единого отставания для них, а затем вы можете попытаться сделать цели спринта сосредоточенными на отдельных продуктах, чтобы команде разработчиков не нужно менять свое "окружение" в середине спринта (но это бонусное очко, а не обязательное).
Главное, если возможно, чтобы этот единственный ПО управлял этим единственным резервом, то, в конце концов, он будет таким же, как если бы ваши текущие 5 ПО стали заинтересованными сторонами, они спросят, чего они хотят, и этот единственный ПО поставит эти вещи. с целью. На основании чего? это может быть необходимо компании, если есть проблемы с блокировкой, или это может быть так же просто, как деньги... кто больше всех платит и тот, кого вы будете посещать первым.
В резюме, снимите с себя ответственность за выбор задачи, которая должна быть разработана командой, это может быть с помощью этого единственного подхода к ПО, форума между ПО, где они вместе управляют одним и тем же продуктом. И это мои 2 предложения.
Слишком много факторов, компания, общее видение и потребности ПО, причина, по которой все это управляет одной командой... и т. Д.
В настоящее время мы работаем с одной командой для нескольких продуктов, и у нас есть только одно ПО и один бэклог продукта, и все идет гладко.
Надеюсь это поможет! Любые сомнения просто скажи мне!
Сначала я сделаю некоторые предположения:
- Продукты слабо связаны - например, если ваша компания производит программное обеспечение для работы с персоналом, это могут быть расписание, обучение, управление эффективностью и т. Д.
- Существует определенный объем общего кода между продуктами, например, вход в систему, ведение журнала, развертывание и т. Д.
- Возможно иметь меньшие команды, которые будут обладать навыками, необходимыми для доставки функций продукта.
- Владельцы продукта могут понять бизнес-ценность функции продукта и договориться между собой о приоритете.
В этом случае я бы...
- Разделитесь на 3 команды по 6/7 - достаточно людей, обладающих навыками, чтобы выполнить важные функции.
- Пусть 3 команды "владеют" 1 или 2 продуктами - так, чтобы команда могла реально понять и внести свой вклад в долгосрочное видение продуктов, а также обеспечить надлежащее расстановка приоритетов в технических вопросах, связанных с ценностью продукта.
- Иметь задание для каждой команды - это владелец продукта (ов) и команда.
- Иметь явный метод, который владельцы продукта используют для определения приоритетов функций - например, ценность для бизнеса, WSJF, Kano и т. Д. Согласие и запись этого могут помочь прекратить споры по поводу подхода
- Попросите 3 команды скоординировать изменения в общем коде - возможно, подход типа Inner Source.
- Попросите тренера помочь команде и заинтересованным сторонам пережить изменения.
Может быть, слишком много открытых фронтов? Сделайте шаг назад, чтобы пересмотреть цели своих компаний, подумайте о снижении ожиданий и соответственно реорганизовать команды. Если вы откладываете товар и делаете 4 товара вместо 5 - это еще не конец света. Это даст вам хороший импульс в других продуктах. Будь умным и выбирай свои сражения. Вам не нужно сражаться в каждой битве, чтобы выиграть войну.
Это общая проблема, которая может быть решена с помощью дисциплины и командной работы.
5 продуктов кажутся очень подходящими для 20 человек, и, надеюсь, некоторые из этих работ похожи, и вы можете включить их вместе. Я бы посоветовал группе сформировать меньшее количество команд из 6+-3, и пусть они выбирают, как лучше всего выполнять работу.
Если у вас есть самоорганизующийся набор команд, они смогут понять, как правильно тренироваться, чтобы вам не понадобилось так много специалистов. Взгляните на Scrum Guide ( http://www.scrumguides.org/) и следуйте там руководящим принципам.