Команды Scrum против традиционно организованных команд

Question

Те из вас, кто начал использовать схватку в ваших командах разработки: Вы поддерживали традиционные команды или формировали новые? В нашей организации мы разделены на базы данных, разработки продуктов и разработчиков интерфейса (упрощено!).

Меня интересуют, действительно ли другие реорганизовали всю свою структуру команды из-за схватки или вы создали специализированные команды проекта (?), Объединяющие, например, один человек каждой «старой» команды.

Answer 1

На самом деле я даже не представляю, как может работать схватка, если вы поддерживаете свою роль бункеры. В схватке мы создаем вертикальные срезы через продукт, чтобы каждая функция, предоставляемая во время спринта, требовала всех навыков, которые вы упомянули (плюс QA, которых вы не сделали). Как бы вы создали постоянное сотрудничество и чтобы люди совершали спринт, если они не все были в одной команде? Похоже, самый вероятный способ закончить «Scrumfall» для меня. Я не эксперт каким-либо образом, но мне кажется, что верный способ потерпеть неудачу в схватке - это думать об этом как о решении по управлению проектами, а не о всех организационных изменениях. Его культурная значимость.

Ответьте на вопрос о «универсалах». Легкий ответ заключается в том, что, имея определенные люди, которые могут работать только на определенных вещах, вы создаете большие жирные узкие места в получении Готово. По специальностям вы всегда ограничены на каждом шаге, имея ограниченные ресурсы для работы над чем-то. В спринте 1 у вас может быть много работы db, чтобы сделать, где есть больше, чем только один dba может сделать. Но затем в спринте 5, где вообще нет изменений в datamodel, ваш dba будет сидеть вокруг, скучая. В планировании спринта становится практически невозможным совершить сделку в разумные сроки, если вам нужно разделить и назначить на уровне задачи роль, а не просто захватить следующий набор приоритетных функций, которые соответствуют скорости вашей команды. Модель обобщения неизбежно приведет к увеличению стоимости бизнеса в долгосрочной перспективе. Вы можете просто не видеть его сразу, пока не достигнете перекрестного опыления.

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

Когда я работал у своего предыдущего работодателя, компания повторно провела всю организацию разработчиков и управление продуктами. В каждой команде были поставлены инженеры, qa и аналитики. Разделение было главным образом вертикальным/функциональным с некоторыми исключениями. Эти исключения были ошибкой - вертикаль архитектуры не соответствовала, потому что она была действительно горизонтальной. Я думал, что кросс-функциональные команды работают хорошо. В вашем случае подразделения db и front-end необходимо объединить с остальными, если это возможно, и могут быть созданы новые вертикали, специфичные для вашего продукта.

Answer 6

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

Answer 7

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

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

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