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 не может быть частью команды разработки. Но он несет личную ответственность за ценность требований для рынка и пользователей, а также отвечает за взаимодействие с рынком.

См. также

Болезни роста: эволюция отдела разработки

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

Многие руководители считают, что сто человек работают в сто раз эффективнее, чем один. Однако масштабирование – нелинейный процесс. Производительность большой команды не всегда равна сумме производительностей ее членов. Как сделать так, чтобы члены команды усиливали друг друга, а не тормозили? Компания ИСВС проходила этот путь и знает ответ!

12.04.2024    1522    0    vasilnikol    18    

27

Деловая переписка. Как выедать мозг чайной ложечкой через письма и получать нужный результат

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

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

27.02.2024    1095    0    user1561517    3    

13

Нетрадиционные методы работы с пользователями или вредные советы от опытного руководителя проекта

Мотивация Бесплатно (free)

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

13.02.2024    799    0    izybaevda    5    

15

Радио "Аналитик", 12 выпуск 2 сезона. Про архитектуру, архитекторов и аналитиков в сфере IT c Александром Кварцхава. Часть 2/2

Проектирование Проектирование бизнес-процессов Управление конфликтами Кейсы продуктов Бесплатно (free)

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

05.02.2024    489    0    Radio_Analyst    0    

1

Диагностика команды в преддверии больших изменений

Фасилитация Бесплатно (free)

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

25.01.2024    427    0    suhovnina    0    

1

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

15.01.2024    1810    0    KChebykina    0    

32

DevRel: почему им стоит заняться уже сегодня

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

DevRel (developer relations или просто технический пиар) – направление развития и поддержки IT-бренда компании: почти как PR (Public Relations), только в центре внимания находятся технические процессы и технологии, а не маркетинг. О том, зачем DevRel нужен компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом, пойдет речь в статье.

09.01.2024    1790    0    a_plastinin    2    

17

Завал в IT-компании и как с ним бороться

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

Работа в режиме завала и в режиме нарастающего завала. Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию «наблюдателя» - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. Вот тут и начинается: "Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать «что-то»".

25.12.2023    754    0    simon_sidoruk    1    

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


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

Product owner не может быть частью команды разработки
Оставьте свое сообщение