какие роли являются частью scrum команды
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Scrum: Действующие лица
May 23, 2018 · 6 min read
Базовое руководство по Scrum — Scrum Guide — весьма лаконичный документ. Не всегда можно сразу понять, что имели ввиду авторы и, тем более, почему.
Попробую рассказать о базовых принципах другими словами. Начну с команды.
Как ранее писал про Agile — основная область применимости Scrum — создание новых сложных продуктов, инноваций, работа в режиме неопределенности, когда не до конца понятно что создавать или как делать.
Как можно создать успешно новое и сложное? Научным путем, путем проб и ошибок. Сделать — собрать отзывы, обратную связь — уточнить видение — сделать следующий вариант. Пока не получится успешный вариант.
Чтобы делать много вариантов, тестировать, проверять, искать решение, нужна организация работы, которая позволяет быстро создавать и проверять гипотезы.
Скрам-команда (Scrum Team)
Суть Scrum — небольшая команда людей. (Scrum Guide)
Какой должен быть состав команды, которая может быстро проверять гипотезы? Скрам-команда (Scrum Team) включает в себя всего три роли:
Владелец продукта (Product Owner)
Владелец продукта отвечает за достижение максимальной ценности продукта.
Часто в работе над проектом руководство осуществляют несколько людей — менеджер по маркетингу, менеджер проекта, технический менеджер и так далее. Главные недостатки:
Задержки с принятием решения замедляют работу команды. Сначала тебе нужно понять, к кому обратиться за решением. Он не может принять сам, должен согласовать. Эффективность команды падает. Переключение на другие задачи — плохое решение. Рост количества “зависших задач”, переключения между задачами — потери. Чтобы избежать потерь, должен быть один единственный человек, который
Владелец продукта — единственный человек, отвечающий за список требований к продукту и ответственный за результат работы команды. Роль объединяет в себе функции разных ролей спонсора, менеджера продукта, руководителя проекта, менеджера по маркетингу, представителя клиента, участника команды. Всегда доступен команде, чтобы разъяснить требования или принять необходимые решения. Но не имеет формальной власти над командой разработки, является частью общей scrum-команды и должен быть не только лидером, но и хорошим командным игроком.
Роль владельца продукта — это краеугольный камень успешного применения гибкого управления продуктом в Scrum. Времена одиноких менеджеров продукта, запирающихся в кабинете и напрягающих мозги, чтобы разработать идеальные требования, прошли. Владелец продукта — это член scrum-команды, он готов к тесному и постоянному сотрудничеству.
Роман Пихлер. “Управление продуктом в Scrum”.
Из-за принципиальных отличий в полномочиях и зоне ответственности в Scrum используется термин владелец продукта, а не привычный менеджер продукта. Если не дать другое название, не будет однозначно понятен объем полномочий и ответственности человека. Начнется путаница. Прозрачность — один из главных принципов Скрам, и четкая отдельная терминология служит именно прозрачности.
Команда создания продукта (Development Team)
Один в поле не воин, нужна команда. Команда создания продукта — самоорганизующаяся, кросс-функциональная команда, которая на выходе каждой итерации создает потенциально продаваемый вариант продукта. Размер команды — от 3 до 9 человек. Для команды меньше трех человек нет смысла вводить какие-то практики. В командах больше 9 человек будут сложности с координацией и взаимодействием.
Внутри команды есть только одна роль — developer. Других должностей, ролей, под-команд — не должно быть.
Почему так и кто такой Developer?
Сталкивался со статьями, в которых пишут — разработчики ускорились с помощью Scrum, что привело к сбоям в работе тестировщиков (QA). Такая ситуация — следствие неправильной трактовки. Никакого отношения к Скрам не имеет. В Скрам команда должна выдать потенциально готовый к продаже продукт, а не кусок кода, требующий тестирования. Тестирование, развертывание — входят в понятие готового к продаже продукта. Эти работы должны выполняться внутри команды. Так мы приходим к следующем термину.
Кросс-функциональная команда — в команде должны быть все знания и навыки, позволяющие создать готовый к продаже продукт. Если говорить о программном продукте, то это дизайнеры, аналитики, программисты, тестировщики, devops-инженеры и так далее. Все, кто необходим. Если каких-то людей нет в команде, возникает необходимость обращения к внешним ресурсам, работающим по другим правилам. В этот момент работа замедляется или останавливается. Если команда полностью автономна, как с точки зрения знаний, так и полномочий, она может работать в своем темпе и результат зависит только от команды. Если команда зависит от внешних людей, у которых другие цели, приоритеты и правила, эффективного результата добиться будет очень сложно. Автономность принятия решения обеспечивает владелец продукта, автономность по навыкам — кросс-функциональность команды.
Теперь появляется противоречие:
Кроме того, люди могут болеть, уходить в отпуск. Требуется перекрытие по навыкам. Что делать?
Чтобы разрешить противоречие, необходимо, чтобы люди не только выполняли одну задачу, а могли помогать другим членам команды. Вместо узко-направленных специалистов (specialist или I-Shaped people) в команде требуются люди с широкой квалификацией, Т-образные личности (T-Shaped people или generalist). Скрам не требует, чтобы все люди были T-Shaped и обладали всеми навыками. Важно, чтобы все необходимые навыки были внутри команды, а какой комбинацией людей и навыков это будет решено — дело самой команды.
Кросс-функциональность, малый размер команды, широкие навыки, заменяемость и нацеленность на продукт, как на общий результат, приводят к отсутствию должностей или ролей внутри команды. Такое деление будет мешать команде, а не помогать ей.
Без должностей, с перекрытием и помощью друг другу, команда сама начинает решать как ей лучше работать. Появляется самоорганизующаяся команда — группа, которая сама умеет решать, как ей управляться с повседневными задачами. Коллективный разум, который мощнее индивидуального.
Скрам-мастер (Scrum Master)
Описанные выше правила работы не привычны. Для всех. Это достаточно серьезное изменение в работе как самой команды, так и её взаимодействии вовне. Любое изменение — всегда стресс, люди психологически всегда противятся изменениям. Как произвести изменения грамотно, организовать работу по новым непривычным правилам, и добиться успеха?
Для этого появляется новая, многим непонятная роль скрам-мастера. Основная ответственность скрам-мастера — организовать эффективный процесс. Скрам-мастер и владелец продукта дополняют друг друга. Владелец продукта нацеливается на создание лучшего продукта, скрам-мастер — на создание правильного процесса. Правильный процесс приводит к правильному результату. Сделать из индивидов самоорганизующуюся команду, способную эффективно решать инновационные задачи с высокой степенью неопределенности.
Скрам-мастер, как и владелец продукта, должен совмещать в себе одновременно много ролей.
В чем цель scrum-мастера? Она — в стремлении построить самоорганизующуюся команду и обеспечить самоорганизацию как ключевой принцип компании на всех уровнях. Самоорганизация порождает чувство вовлеченности и обязательности, делает людей более активными и ответственными. А это, в свою очередь, дает команде возможность находить собственные решения и делает ее более эффективной. Самоорганизация является ключевым аспектом высокой производительности команды, но не в краткосрочной, а в долгосрочной перспективе. Она позволяет по мере необходимости улучшать и адаптировать процессы, коммуникацию и сотрудничество. Создает сотрудников с высокой мотивацией, а будучи примененной к группе людей, помогает им выстроить настоящую команду — с едиными целью и идентичностью.
… Помните Scrum-мастер является проводником на пути agile-трансформации. Scrum-мастер должен держаться не более чем на один шаг впереди команды и организации, вытаскивая их из устоявшихся привычек и обычаев.
Зузана Шохова. “Путь скрам-мастера”
Если внимательно изучать Скрам, то принципы, лежащие в его основе, весьма логичны. Кратко резюмируя по ролям команды, чтобы создать нечто новое, Скрам предлагает:
Будь гибким: как понять Scrum и создать agile-команду
Scrum — методология гибкого процесса разработки программного обеспечения. Сейчас этот метод управления популярен и активно применяется.
Прежде чем разобраться, что такое Scrum и как внедрить эту методологию, давайте посмотрим на предпосылки её возникновения.
Как и зачем появилась Scrum-методология
До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.
Разработчики согласовывали план работы с заказчиком и чётко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому, если выявлялись ошибки, приходилось начинать всё сначала, а сроки работы увеличивались.
Так было, пока группа новаторов не решила изменить ситуацию полностью. Они наблюдали за тем, как работают успешные команды: не срывая сроки и получая именно тот результат, который планировали. Оказалось, что успех обеспечивала гибкость процесса.
Выводы, которые были сделаны, помогли создать «Манифест гибкой разработки программного обеспечения». В него вошли всего четыре пункта, но они полностью изменили процесс.
Манифест гибкой разработки ПО
1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.
Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы 12 принципов, которые и сейчас используются в любой Agile-методологии.
12 принципов Agile
1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.
Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.
Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.
Принципы Scrum
Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами)
Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.
Гибкость. «Проверять и адаптироваться»
Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта
Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.
После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.
О важности scrum-команды
Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трёх человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.
Состав команды
Принципы работы scrum-команды
Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.
Совершенствование продукта за счёт самосовершенствования сотрудника.
Каждый член команды отвечает за свою часть работы и за общий результат.
Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.
Процесс работы scrum-команды
Процесс работы scrum-команды проходит в несколько обязательных этапов.
Каждый спринт начинается с планирования. Scrum-мастер, владелец продукта и остальные члены команды вместе смотрят на бэклог продукта и выбирают направления, по которым будут работать в данном цикле. Так получается бэклог спринта, то есть список задач на этот период.
Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.
Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:
Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.
Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.
Если кто-то из членов команды понимает, что не укладывается в спринт, он сообщает владельцу продукта, а тот распределяет время иначе. То же самое происходит, если команда понимает, что справится с задачей досрочно, — тогда можно добавить дополнительных задач из бэклога продукта.
Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.
Как внедрить scrum-методологию
Сейчас методология Scrum находится на пике популярности. Вопрос о её пользе уже почти не звучит. Но как внедрить Scrum правильно, чтобы заметно улучшить ситуацию с продуктивностью и качеством итогового продукта?
Кажется, что всё просто. Нужны несколько последовательных действий.
Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.
2. Назначить владельца продукта
Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.
3. Выбрать scrum-мастера
Scrum-мастер — важная часть команды. От него зависит, насколько комфортно всем участникам процесса будет работать. Тут нужен опытный scrum-мастер, который хорошо знаком с методологией не только в теории.
4. Создать список требований к продукту
Прежде чем начать разработку, стоит подумать над списком требований и согласовать их. Получится своего рода техническое задание, которое будет направлять работу.
5. Спланировать спринт
Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.
6. Постоянно анализировать и оценивать результат
Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.
Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?
Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом. Поэтому важно учиться только у тех, кто знает, что такое Scrum, на практике, разбирается во всех тонкостях не только методологии, но и её внедрения в конкретную область. Ведь этот процесс сильно зависит от продукта, который вы собираетесь создавать с помощью Scrum.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.