Как реализовать Scrum с тремя аналогичными веб-продуктами
Я немного знаком с концепциями и преимуществами Scrum. Имея это в виду, я пытаюсь улучшить неудовлетворительную структуру управления продуктами Scrum в компании, в которой я сейчас работаю, которая имеет три отдельных продукта B2C, ориентированных на одну и ту же демографию и доступных на одном веб-сайте. У каждого продукта есть владелец продукта и уникальная команда разработчиков.
Учитывая, что целевые аудитории схожи (не уверен, что это должно иметь значение), а 3 веб-продукта схожи по своей природе, каковы потенциальные выгоды / риски, связанные с объединением команд и наличием только одного владельца продукта и одной команды разработчиков? Некоторые вопросы, которые приходят на ум: имеют ли смысл иметь 3 владельца продукта и три отдельных бэкла, если на вашем сайте есть три различных продукта? Кроме того, если у вас есть только один владелец продукта, какой из показателей лучше всего выбрать, кем он будет?
6 ответов
Это не проблема команды, а скорее вопрос управления. Как Scrum Master, ваша роль - тренировать дисфункцию, и в этом случае вы выдвинули на первый план кое-что вызывающее беспокойство; в этом есть несоответствие между продуктами и возможно не оптимальная работа команды.
Проверьте свои наблюдения с существующими владельцами продукта и определите, считают ли они это проблемой или нет. Владельцы каждого продукта имеют право выбирать, как они будут управлять этим. Так как эти разные веб-сайты могут быть непоследовательными и влиять на бренд компании, это решение ОО делать / не делать, так как это их риск.
Если они чувствуют, что бренд находится в опасности, тогда следует собрать три команды вместе (для встречи) и представить всем им одну и ту же проблему. Затем попросите их решить и посмотреть, что они придумали.
Некоторый дополнительный контекст был бы полезен.
Насколько велики команды? (Помните о руководящих указаниях по размеру команды 7 +/- 2.) Они кросс-функциональны?
Что придает каждому продукту индивидуальную индивидуальность? И наоборот, что можно было бы получить, добавив "биологическую и технологическую особенность" каждого продукта в продуктовый коллектив?
Как часто вы развертываете в Интернете?
Прежде чем посмотреть, что делать с командами, постарайтесь выяснить, что вызывает сбои.
Вы проводите ретроспективу? Предложите ли команде какие-либо решения / предложения о том, как улучшить (scrum подчеркивает командную и личную ответственность - команда должна быть участником решения)
Несколько ПО почти наверняка приведут к более хаотичной обстановке для команды. Частью элегантности ПО является предоставление команде одного человека для окончательного утверждения вопросов "Что".
Но я забегаю вперед - во-первых, понимаю проблемы очень хорошо.
Вам нужно объединить команды? Я не знаю, но правило 7 +- 2 - довольно хорошее эмпирическое правило. Если вы работаете над подобными вещами, возможно, вам нужна команда архитекторов. Может быть, конфигурация вашей команды в порядке, но есть некоторые другие зависания в вашем рабочем процессе.
Сильно подумайте о привлечении хорошего тренера по схватке. Существует множество консультантов по обучению и коучингу, и эти ребята путешествуют по стране, помогая таким людям, как мы, быть реализованными.
Я реализовал scrum дважды, и я могу честно сказать, что он не пошел бы так же хорошо, как если бы не было обучения. (У вас также должна быть спонсорская поддержка со стороны руководства - во-первых, если мои реализации позволили мне привлечь даже ИТ-директора к участию в тренинге - это было трансформационным)
Подумайте просто: если вы собираетесь объединить все три продукта в один, то вам придется делать то же самое с ПО, но если ваши продукты будут продолжать жить отдельно, вам придется сохранять ПО на каждый продукт.
Я бы предположил, что "схожий характер" приводит к таким проблемам, как "два продукта имеют одинаковую функцию" или "каково общее направление, в котором идут все три продукта и как они мешают". Чтобы решить такие проблемы, вы можете использовать "разборки", обычно это еженедельное собрание, в которое входят все члены команд, где каждая команда делится своими целями для предстоящего спринта. Такое сотрудничество помогает лучше понять, кто чем занимается и как влияет на всю систему.
Вы заявляете о "несостоятельности структуры управления продукцией компании Scrum", я бы посоветовал вам начать с попытки точно понять, что не так с текущим процессом компании.
Я бы очень осторожно относился к простой попытке слияния трех команд, поскольку это могло бы быть очень разрушительным для корпоративной культуры, вызывать сопротивление и все равно не дать вам желаемых результатов.
Хороший способ понять текущие ошибки - это найти способ визуализации вашего рабочего процесса. Это должно помочь выявить любые узкие места и / или пропущенные ожидания в течение жизненного цикла разработки.
Канбан является отличной техникой для этого, и не требует каких-либо новых процессов или изменений, которые должны быть внедрены! Просто нарисуйте свой текущий рабочий процесс через дорожки для плавания на белой доске, попробуйте ограничить количество WIP на доске и проводите ежедневные встречи на доске объявлений Kanban. Это должно позволить вам очень быстро понять и определить, что не работает в текущем процессе.
Я также рекомендую "Lean from the Trenches" Хенрика Книберга в качестве другого замечательного ресурса.
"Схожие целевые аудитории" не являются хорошим основанием для объединения команд.
Три продукта - хорошая основа для трех команд, в пределах ограничений размера команды. Команда должна быть достаточно большой, чтобы включать в себя все необходимые навыки, и при этом быть достаточно маленькой, чтобы исключить избыточные каналы связи.
Кроме того, невозможно помочь вам определить, почему они "не работают в Scrum", не имея гораздо большего контекста, который вы, похоже, не желаете предоставить.
Поэтому единственные предложения: нанять высококлассного тренера по схватке или, если это невозможно, определить запахи и применить рецептивные решения.