Каков наилучший способ масштабирования и разделения гибкой команды при создании веб-приложения?

Недавно я присоединился к компании, где я работаю мастером по разработке гибкого проекта по созданию веб-приложения.

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

В проекте есть два совершенно разных уровня - высокотехнологичный бэкэнд-разработчик (например, очень сложный) и дизайн / сборка / интеграция пользовательского интерфейса. Кажется, что, когда бэкенд-ребята разговаривают технически, ребята из пользовательского интерфейса отключаются, и наоборот. Это кажется логичным способом разделить команду, хотя бы для того, чтобы сэкономить время, но у меня есть одна серьезная оговорка: все, что я мог бы на самом деле делать, - это сокращать сотрудничество и обмен знаниями. У двух команд просто не будет хорошего представления о том, что строит остальная команда.

У кого-нибудь есть опыт общения с чем-то подобным?

К сожалению, ребята из UI не заботятся о деталях сложной серверной работы. Это больше похоже на тему обсуждения для ретроспективы. Разделение команды по дисциплине создало бы опасный прецедент, как скоро это произойдет, прежде чем ребята из Requirements начнут зонировать и не будут заботиться о том, что делают ребята из UI, и просят собственную команду.

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

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

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

Ура!

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

У каждой из новых команд должен быть руководитель группы / технический менеджер, который хорошо осведомлен о масштабах своей команды, а также знаком с работой других команд.

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

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

Ключевым аспектом Scrum является самоорганизация .

Я предлагаю вам обсудить вопрос с командой, и пусть они решат его.

Все ваши опасения обоснованы, но помните, что как Scrum Master, ваша задача - тренировать и помогать. Поэтому спросите их, как они решат эти проблемы. Они будут владеть решениями и заставят их работать.

Я бы добавил: в общем, кросс-функциональные команды - это путь.

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

1. Как далеко находится интерфейс от сервера? Как и ожидалось, расщепление - это хороший совет, только если расстояние слишком велико.

   • Если бэкэнд говорит о схеме базы данных, это не так уж далеко . И передний, и внутренний должны прислушиваться к обсуждению схемы базы данных.

   • Если в бэкэнде говорится о шардинге, кэшах памяти, задержке диска и т. Д., То это слишком далеко (где бэкэнд фокусируется на механической симпатии и оптимизации, а интерфейс - на человеческой эстетике).

2. Существует ли стабильный и однозначный программный интерфейс между интерфейсом и сервером?

   • Благодаря стабильности и однозначности это означает, что пользователи этого интерфейса программирования (внешние разработчики) не будут увязать в изменениях и не будут нуждаться в чтении стен текста, чтобы научиться правильно его использовать.

   • Команда разработчиков должна предоставить хороший API и пробную реализацию на ранней стадии, и только после этого начать реальную разработку.

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

3. Почему так много проворных статей рекомендуют иметь вертикальные срезы? Вот некоторая справочная информация:

   • Большинство проворных статей на самом деле рекомендуют избегать серверной работы с точки зрения затрат.

   • Также не забывайте, что у части проворных статей был явный уклон к компаниям запуска.

   • И не забывайте суровую реальность маркетинга - большинство клиентов платят только за внешние интерфейсы.

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

   • Большинство проворных статей также рекомендуют реализовать внешний интерфейс, чтобы он мог выдержать переключение внутреннего интерфейса. Этот совет идет рука об руку с предыдущим: если готовая технология не отвечает всем требованиям, попробуйте другой.

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

   • Стабильные бэк-энды
   • Стабильный API
   • Низкий уровень брака
     • Причина: чтобы избежать разочарования
     • Как: модульное тестирование
     • Не значит: производительность или оптимизация; это просто должно быть функционально правильно.
   • Непрерывная интеграция
   • Прозрачность в общении, прогрессе и принятии решений
   • Поощрять неформальные обсуждения между двумя командами
   • Поощряйте членов команды (тех, кто не разбивается на зоны) посещать собрания другой команды.
   • Назначать случайные совместные встречи и совместные ретроспективы
   • Другие командные мероприятия

Как и другие, я бы определенно предложил использовать вертикальные срезы. Их иногда называют «художественными командами». Я бы порекомендовал почитать плюсы и минусы на сайте Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

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

1. Agile Team 1: SM, PO, Межфункциональная команда. Имеет собственную команду отставание для своих историй.
2. Agile Team 2: SM, PO, кросс-функциональная команда. Имеет собственную команду отставание для своих историй.
3. Команда управления программой: менеджер по продукту, менеджеры по выпуску, корпоративные архитекторы. Имеет собственную программу невыполненных работ по эпосам и функциям более высокого уровня, которые будут организованы, проанализированы, а затем поданы в команды.

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