Я являюсь тренером по Agile для команды, состоящей из 4 совершенно разных платформ (iOS, Android, Javascript, Windows), в каждой из которых работает 1 или 2 инженера. Всего есть 2 автоматических/ручных тестера и 1 PO.
Все 4 платформы работают с одним и тем же бэклогом пользовательских историй (у нас есть отдельные одинаковые пользовательские истории для каждой платформы.
В настоящее время у нас есть одна канбан-доска в Jira, извлекающая данные из 4 разных проектов. У нас есть своя дорожка для каждой платформы, но у нас общие лимиты WIP, стендапы, ретро и демоверсии.
Текущие проблемы:
Вопрос в том, должны ли эти платформы быть разделены на 3 разные команды или какую технику я могу использовать, чтобы исправить это?
Если вы не можете предоставить единую цель спринта, которая позволит всем инженерам сосредоточиться на одном результате, важном для всех, то иметь единую команду будет мало смысла.
Если у вас в команде всего 2 человека, то накладные расходы на Scrum и другие agile-практики будут немного излишними. Просто разделите их на команды по два человека и выясните, как выполнить отставание от своей платформы/продукта.
Однако, если у вас может быть единая цель, тогда они должны заботиться о работе друг друга на Daily Scrum. Это вернет им фокус и позволит им работать вместе, а не по отдельности.
Похоже, у команды слишком много усилий, а PO недостаточно.
Команда, имеющая 4 одинаковых элемента невыполненной работы, — это большой красный флаг. Если вы начинаете с одного, а затем разделяете его для них, это просто активирует поведение. Оставьте это как один, и команда в целом либо закончит его, либо нет. Иногда поначалу команды могут оставаться обособленными и эффективно продвигаться вперед по коллективным элементам невыполненной работы, но для сохранения равновесия необходим почти невероятный набор совпадений. Как только кто-то уходит в отпуск или одна платформа сталкивается с проблемой, потребность в членах междисциплинарной команды становится очевидной. Отсюда вы можете тренировать команду на любом пути вперед (а их много), который помогает им решить эту проблему.
Слово предупреждения, когда вы решаетесь на это: я столкнулся со многими разработчиками, которые сопротивляются этому, потому что они не хотят быть мастерами на все руки, и это вполне разумное мнение. Насколько неразумно со стороны разработчиков думать, что они могут освоить один навык и заставить компанию обслуживать этот бункер, настолько же неразумно для компании думать, что все должны развивать все навыки. Вам нужно достаточное количество совпадений, чтобы команда не была хрупкой в плане навыков. Точное количество перекрытий будет разным для каждой команды, и скрам-мастер должен помочь им найти его, а не принуждать к этому.
Не говорите о скучных технических вещах в повседневной жизни. Говорите о процессе, блокировщиках, продукте и т. д. Требуйте, чтобы члены команды уважали друг друга в течение 15 минут каждый день, активно слушая друг друга.
Это все тот же правильный продукт, та же организация и тот же процесс, вы все еще используете тот же бэкенд или API, поэтому 90% того, что обсуждается в ежедневном чате, должно быть интересно всем. Можно упоминать вещи, специфичные для платформы, и их все равно следует слушать, но это должно быть только 10%.
И поскольку вы хотите, чтобы эти пользовательские интерфейсы работали одинаково на разных платформах, это также следует обсудить, так что больше похоже на 95% общих вещей, 5% специфичных для платформы.
Имеет смысл, что специалисты не работают так тесно друг с другом, если они разрабатывают отдельные интерфейсы, поэтому не ожидайте от этого многого. На самом деле подумайте, что они должны тесно сотрудничать, чтобы интерфейсы не слишком отличались друг от друга и работали примерно одинаково на разных платформах.
Постарайтесь быть более ориентированным на продукт, чем на платформу. Включите в команду back-end и бизнес-парней.
Похоже, что Владелец Продукта не создал Видение Продукта для конечного продукта, над которым он работает. Это было бы хорошей отправной точкой, чтобы заставить всех разделять общее мнение.
Во-вторых, я согласен с @Daniel, наличие 4 одинаковых историй для каждой является красным флагом и не создает общего бэклога продукта. Создайте только одну историю для каждой функции и попросите каждую мини-команду из 2 человек выполнить свои задачи, а затем встретиться и поделиться прогрессом и любыми препятствиями. Делая это два раза в день, они должны оставаться на одной странице и быть более готовыми помочь друг другу в случае необходимости.
Чтобы это сработало, история должна иметь четко определенные критерии приемки; не только как вопросы, которые нужно задать, но и с учетом каждой из 4 платформ, для которых разрабатывается. Это похоже на проверку (тестирование) того, что функции веб-страницы работают одинаково в разных версиях Windows и в разных веб-браузерах для каждой версии.
Главное — дать им набор общих ценностей, которые объединят их для достижения одной цели.