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

В этой статье мы разберемся с ролями Scrum и поговорим о том, как вы можете использовать их в своей организации, не печатая новые визитные карточки.

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

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

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

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

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

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

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

Представьте, что у вас есть дом и вы нанимаете «разработчика». Он разрабатывает проект и выполняет работу. Да, он может класть кирпичи, заниматься водопроводом и даже копать огромные ямы, но этот человек все равно просто «разработчик». Это значит, что роль «разработчика» в Scrum означает участника команды, который обладает определенными навыками, необходимыми для выполнения работы в команде.

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

В обязанности команды разработчиков входит следующее.

• Поставка результатов работы через спринт.

• Для обеспечения прозрачности во время спринта они встречаются на ежедневном scrum-собрании (иногда его называют стендапом). Ежедневное scrum-собрание способствует прозрачности работы. На нем участники команды могут обратиться за помощью, рассказать о своих успехах, указать на проблемы и блокеры. Scrum-мастер может оказывать содействие в проведении ежедневных scrum-собраний, но в конечном итоге ответственность за проведение этих встреч лежит на команде разработчиков. Такие собрания помогают команде контролировать и адаптировать выполняемую работу и работать более эффективно.

Владелец продукта в Scrum определяет требования клиентов и бизнеса, а затем на их основе создает бэклог продукта и управляет им. Agile-команды по определению являются гибкими и быстро реагируют на изменения, поэтому владельцу продукта необходимо обеспечить максимальную ценность. Он играет роль представителя компании и сообщает разработчикам, чего требуется достичь. Доверие между этими двумя сторонами имеет принципиальное значение.

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

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

Команды, следующие принципам Agile, по своей сути предусматривают анализ и адаптацию. Это означает, что изменение приоритета может привести к серьезным изменениям в структуре команды, рабочих продуктах и конечном результате. Именно поэтому для успешной работы scrum-команд крайне важно, чтобы определением приоритетов занимался только один человек. Это владелец продукта.

В руководстве по Scrum выделяют следующие обязанности владельца продукта.

• Управление бэклогом Scrum. Это не означает, что только лишь владелец продукта вносит новые задачи в бэклог продукта. Но в конечном итоге именно он несет ответственность за бэклог, в соответствии с которым команда разработчиков поставляет продукт. Это значит, что владелец продукта должен знать обо всем, что находится в бэклоге продукта, а другие люди, добавляющие задачи в бэклог, должны обращаться к владельцу продукта. Мы даже предлагаем бесплатный шаблон Scrum, который позволяет без труда настроить и запустить бэклог.

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

• Управление заинтересованными сторонами. Любой продукт имеет множество заинтересованных сторон, от пользователей, клиентов, администрации и до руководителей организации. Чтобы поставка ценности командой разработчиков была эффективной, владельцу продукта необходимо работать со всеми этими сторонами. Это может включать большой объем коммуникаций и работы по управлению.

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

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

Scrum-мастер фокусируется на следующем.

• Прозрачность. Для проведения эффективного анализа и адаптации важно, чтобы нужные люди могли видеть происходящее. Но добиться этого гораздо сложнее, чем кажется. В задачи Scrum-мастера входит обеспечение прозрачности работы Scrum-команды. Для этого, например, создаются карты историй или вносятся в Confluence идеи по результатам ретроспективы.

• Эмпирический подход. Основная идея подходов Scrum и Agile состоит в том, что лучший способ планирования — работать и учиться на результатах. Эмпирический процесс непрост и требует, чтобы Scrum-мастер обучил Scrum-команду разбивать работу на составные части, четко описывать и оценивать конечные результаты.

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

• Ценности. В Scrum выделяют пять ценностей (смелость, сосредоточенность, ответственность, уважение и открытость) не потому, что они хороши, а по той причине, что они создают атмосферу безопасности и доверия. Эта атмосфера необходима для успешного развития гибкости. Каждый участник Scrum-команды обязан следовать этим ценностям, а Scrum-мастер активно поддерживает такие начинания и напоминает всем об их важности.

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

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

• Если у вас есть много полезных навыков для поставки ценности для клиентов и вам нравится этим заниматься, вам следует быть участником команды разработчиков Scrum. В сущности, эта команда является наиболее важным элементом любой Agile-организации, поскольку она напрямую занимается поставкой ценности клиентам и заинтересованным сторонам. Это означает, что должностное положение определяется тем, как долго вы поставляете ценность или помогаете в этом другим.

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

• Если вы хотите помогать участникам команды эффективно работать вместе, а также менять мир с помощью Scrum и Agile, то вам подходит роль Scrum-мастера. Эта роль полностью ориентирована на людей и уделяет особое внимание коучингу, обучению и содействию.