Scrum-команда: рассказываем, кто все эти люди

10.12.18

Команда - Коммуникации

Scrum – методология, которую стремится внедрить практически каждая небольшая команда, создающая программное обеспечение. Да и в других отраслях она прижилась благодаря логичности, универсальности и эффективности. Но новички, которые попадают в scrum-команду, часто не совсем понимают, что происходит, и какие функции у каждого участника. Разбираемся, какие роли могут быть в scrum-команде.

Что такое scrum-команда

Scrum-команда объединяет людей, которые работают в рамках scrum-методологии разработки. Команда эта самодостаточная: ей не нужны специалисты со стороны, чтобы решать проблемы, помогать или выполнять отдельные части работы. Не входит в scrum-команду и заказчик, а также сопутствующий персонал – менеджеры, специалисты техподдержки и др.

Непременные части  scrum-команды – scrum-мастер, product owner (владелец продукта) и команда разработки (development team). Если все три части будут работать слаженно и в рамках методологии, то в результате каждого спринта (отрезка времени, на который ставятся цели) они будут предоставлять рабочую версию продукта. Она является инкрементом предыдущего результата – старой версии с улучшениями, соответствующими цели спринта.

Инкремент, инкрементирование – операция во многих языках программирования, увеличивающая переменную.

Кто входит в состав development team

Команда разработки – это не только непосредственно разработчики. В эту самую многочисленную часть scrum-команды входят тестировщики и DevOps, и UA/UX-дизайнеры, и другие специалисты, которые обеспечивают создание инкремента продукта. Все зависит от того, как организована работа над конкретным проектом.

 

 

Команда разработки является ключевой рабочей единицей. Глава Amazon Джефф Безос сформулировал «правило двух пицц» для размера scrum-команды – от 4 до 10 человек, то есть то количество людей, которых можно накормить двумя пиццами. Размер и состав scrum-команды на протяжении спринта не меняется.

Что делает scrum-мастер

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

Самое важное в этой истории: scrum-мастер – не начальник. Это не управленец и не «боевая единица», которая действует с позиции строгости, ограничений и наказаний. Основная задача scrum-мастера – разобраться, что блокирует выполнение задач, устранить эти преграды. Scrum выявляет проблемы и обеспечивает их открытое обсуждение. Такой подход порождает доверие внутри команды, а благоприятная атмосфера позитивно влияет на качество и скорость работы.

 

 

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

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

Scrum-мастер в команде всегда один. Обычно его выбирает команда.

Какова роль product owner

Владелец продукта – это не заказчик, а скорее связующее звено между ним и  scrum-командой. В то же время product owner не является сторонним специалистом: он – полноценный член scrum-команды.

У product owner больше ответственности, чем у членов команды разработки, но и ограничений больше. Он формирует  Backlog (бэклог) – список задач, которые нужно выполнить в рамках разработки продукта. Задачи в бэклоге product owner сортирует по их приоритетности.

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

 

 

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

Product owner не может влиять на ход работ во время спринта. Его единственное право – возможность остановить спринт, но это скорее исключительная ситуация. Все остальные решения принимает scrum-мастер.

Проект считается завершенным, когда в продуктовом бэклоге нет требований. Но product owner в процессе разработки вправе менять бэклог, добавляя или удаляя из него элементы –user story (пользовательские истории).

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

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Коммуникации Россия Бесплатно (free)

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

29.07.2026    163    0    NikolayMaerov    1    

3

Коммуникации Россия Бесплатно (free)

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

28.07.2026    133    0    NikolayMaerov    0    

2

Коммуникации Лидерство Бесплатно (free)

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

27.07.2026    538    0    Ferra_Shap    15    

15

Коммуникации Бесплатно (free)

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

23.07.2026    262    0    YA_826532418    0    

3

Коммуникации Внедрение изменений Россия Бесплатно (free)

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

23.07.2026    442    0    NikolayMaerov    5    

5

Коммуникации Россия Бесплатно (free)

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

22.07.2026    246    0    NikolayMaerov    1    

4

Коммуникации Россия Бесплатно (free)

Руководитель показывает сотруднику конкретные ошибки, а в ответ слышит: «Я вообще не виноват». Как выслушать объяснение, признать обоснованные аргументы и при этом не снять ответственность? Разберём, почему эмпатия не требует согласия, а спокойная форма разговора ещё не гарантирует понимания

21.07.2026    257    0    NikolayMaerov    0    

4

Коммуникации Лидерство Руководитель проекта Россия Бесплатно (free)

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

20.07.2026    287    0    NikolayMaerov    0    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. surikateg 10.12.18 20:34 Сейчас в теме
2. TODD22 20 10.12.18 20:40 Сейчас в теме
(1)+100
Как бы зайти на ресурс для программистов и не увидеть очередного адепта или проповедника с горящими глазами рассказывающего про agile, scrum и тд.
3. genayo 11.12.18 06:27 Сейчас в теме
(2) Подозреваю, что большинство таких статей не для читателей, а для самих писателей...
4. TODD22 20 11.12.18 09:42 Сейчас в теме
(3)раньше все делали свои перенумераторы документов. Сейчас каждый считает своим долгом пересказать книжку по scrum, agile и тд
pm74; GoR1313; slavikss; +3 Ответить
5. gudun_ku 62 11.12.18 14:45 Сейчас в теме
Вообще сама методология должна была сделать работу пободрее и повеселее, по идее авторов.
И по рассказам тренеров этой секты. Но во всех тех отечественных конторах, что я знаю, скрам
стал способом превратить процесс разработки в нечто вроде непрерывного обхода в психушке.
6. zayden 18 12.12.18 10:04 Сейчас в теме
(5) знакомлюсь со scrum но выводы примерно такие же)))
7. TerveRus 12.12.18 12:07 Сейчас в теме
(5) не знаю, я лично работал в scrum-команде и не знал, что это scrum) Но все описанное в статье было и понравилось)
Если и буду работать по удаленке, то только в таких командах.
8. Legavaz 712 12.12.18 17:00 Сейчас в теме
В то же время product owner не является сторонним специалистом: он – полноценный член scrum-команды


очень странно.

Product owner не может быть частью команды разработки
Для отправки сообщения требуется регистрация/авторизация