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

См. также

Коммуникации Руководитель проекта 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

17.09.2026    207    0    YA_826532418    0    

4

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

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

03.09.2026    303    0    YA_826532418    0    

4

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

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

02.09.2026    472    0    YA_826532418    3    

5

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

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

02.09.2026    263    0    user2117358    0    

0

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

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

13.08.2026    471    0    irinaaykn    1    

1

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

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

13.08.2026    500    0    G_104938689049837478547    0    

0

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

Delivery – это не доставка еды, а доставка ценности в продакшн: разбираем, как выстроить процесс поставки на примере команды, работающей с 1С:ЗУП. Показываем, как за пару лет удалось почти вдвое сократить срок поставки решений, увеличить количество релизов с пяти до двенадцати в месяц и уменьшить периоды бизнес-фризов – за счет процессов, автоматизации и фокуса, а не переработок. Объясняем, как Lead Time, предсказуемость и другие метрики помогают находить узкие места и оценивать эффективность команды. Делимся практическими кейсами, сложностями и результатами – без лишней теории, только опыт.

12.08.2026    435    0    a_borodavko    0    

27

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

Почему процессы, которые отлично работали в одной небольшой команде, перестают справляться с ростом, а увеличение штата не ускоряет поставку, а лишь усложняет коммуникацию и размывает ответственность? Рассказываем, как перейти от одной функциональной команды к системе автономных доменов, распределить архитектурную экспертизу и избежать ситуации, когда архитектор или платформенная команда становятся «бутылочным горлышком». Разбираем принципы Team Topologies с учетом специфики 1С, рабочие способы межкомандной синхронизации и трансформацию ролей руководителей, тимлидов и архитекторов. Показываем, как выстроить устойчивую ИТ-экосистему, в которой автономия не превращается в анархию, а координация – в бюрократию.

11.08.2026    378    0    Аверков    3    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
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 не может быть частью команды разработки
Для отправки сообщения требуется регистрация/авторизация