Scrum команда
Каждая команда начинает матч с 15 полевыми и 7 запасными игроками. Состав команды включает восемь нападающих (англ. forwards) и семь защитников (англ. backs). Вики
Обязательные свойства:
Самоорганизация
Без самоорганизации петля постоянных улучшений становится слишком длинной или разрывается вовсе (когда предложение об оптимизации процесса попадает в долгий ящик начальника и так и остаётся нерассмотренным).

Самоорганизация так же означает, что команда решает кто, что, когда и почему делает — нет авторитарного органа принятия решений.

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

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

Требование к кросс-функциональности родилось из необходимости минимизировать количество простоев команды и специалистов, и нивелировать формальные передачи работ внутри итерации разработки инкремента, тем самым снизив количество документации.

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

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

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

При разборе неудач равнораспределённая ответственность позволяет сосредоточиться на проблеме, а не искать виноватого, сосредоточится на процессе, который требует корректировки, а не индивидууме, который упустил все полимеры.
Небольшой размер
Руководство по Scrum рекомендует десять или менее человек. Если команда вырастает за пределы этого ограничения, рекомендуется реструктурировать одну команду в несколько команд, при этом у них должен быть:
Важно отметить, что это единственное упоминание о возможностях масштабировать фреймворк в официальном руководстве.

Такие скудные средства масштабирования явились причиной возникновения огромного количества современных фреймворков гибкой разработки, базирующихся на идеях Scrum и с разной степенью успеха решающих эту проблему.
— Мы американский международный разработчик ПО с советским прошлым, мы считаем, что используем Scrum, но состав функций к разработке зафиксирован при продаже проекта, а фазы, спринты и общий план-график спланированы пресейлами заранее до старта проекта, чтобы оценить общий срок проекта.
— Это не спринты и не Scrum, по определению. Самоорганизация команды — обязательное свойство для Scrum, а эмпирическое планирование крайне настойчиво рекомендуемый подход к моделированию итераций. Смоделировать план достаточной точности, чтобы смело продавать проект, можно только проделав глубокий предварительный анализ требований заказчика. У вас традиционный подход к проектному управлению и разработке, часто называемый также "водопад".
Scrum почти никогда не используется на стороне подрядчика, особенно с договорами с фиксированной стоимостью.

Фреймворк создавался для работы внутри компании и не обладает элементами, которые бы позволяли привлекать подрядчиков или тем более быть на стороне подрядчика.
Состав команды
Столб, отыгрывающий, замОк, фланкер, стягивающий, крыльевой, замыкающий... нет, не то
Роли, регламентируемые фреймворком:
  • Мастер по Scrum
  • Владелец продукта
  • Разработчики
Scrum умышленно не уточняет, что такое разработчик.
Кросс-функциональность команды подразумевает, что "разработчик" это собирательный образ всех необходимых специалистов для успешного решения поставленной задачи и неважно это группа узкоспециализированных профессионалов или пара мастеров на все руки.
Это важно:
Scrum обязывает команду содержать все навыки, требуемые для покрытия всех этапов разработки продукта начиная от взаимодействия с заинтересованными сторонами и верификации требований до экспериментов, исследований и в целом буквально всего чего угодно, что требуется для разработки инкремента за итерацию.
Важно заметить, что культура DevOPS, появилась сильно позже 1986 года, а интенсивно развиваться и распространятся начала после десятилетия популярности Scrum на западе.

Scrum команда могла не содержать отдельной роли релиз-инженера или её аналога и это могло приводить к заметным задержкам релизов инкремента. Это было не важно пока спринт длился от 3 до 6 месяцев.

Виталий Новиков
Гл.редактор
Разработчик (Developer)
Основная работа ложится на них
Основные обязанности:
  • планировать спринт
  • поддерживать качество ПО, удовлетворяя определениям готовности
  • корректировать и уточнять план каждый день для достижения Цели Спринта
  • требовать друг от друга профессиональной ответственности
  • непосредственно создавать продукт

В команде может быть один или несколько.
Статьи о Scrum