Скрам-команды против традиционно организованных команд [закрыто]

Question

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

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

Answer 1

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

Чтобы ответить на ваш вопрос о «универсалах». Простой ответ заключается в том, что, имея определенных людей, способных работать только над определенными вещами, вы создаете большие жирные узкие места в достижении «Готово». С специальностями вы всегда ограничены на каждом этапе, имея ограниченные ресурсы для работы над чем-то. В спринте 1 у вас может быть много работы с БД, когда есть больше, чем может сделать только один БД. Но затем в спринте 5, где нет никаких изменений в модели данных, ваш dba будет сидеть без дела, скучая. При планировании спринта становится практически невозможным совершать действия в разумные сроки, если вам нужно разделить и назначить на уровне задач по ролям, а не просто взять следующий набор приоритетных функций, соответствующих скорости вашей команды. Универсальная модель неизбежно принесет ценность для бизнеса в долгосрочной перспективе. Вы можете просто не увидеть это сразу, пока не достигнете перекрестного опыления.

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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