В шапке
Роли в Scrum

Роли в Scrum

Гибкие подходы к управлению проектами набирают свою популярность в Беларуси. Настало время написать подробнее о самом популярном гибком подходе – Scrum.

В одной из статей я рассмотрел в общем, что такое Scrum и как он работает.

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

Документ, который описывает, как работает Scrum (в дальнейшем я буду писать «скрам»), называется Scrum Guide, и его можно получить бесплатно.

В Scrum Guide описано три важные роли – Product Owner (владелец продукта), Scrum Master (скрам мастер), Development Team (команда разработчиков продукта, для простоты я буду писать «команда», хотя в Scrum Guide написано, что все три роли входят в состав команды).

Рассмотрим подробнее, кто и чем должен заниматься в проекте. 

Владелец продукта с точки зрения его роли в проекте больше всего похож на классического руководителя проекта. Он отвечает за бюджет проекта, т.к. определяет, на какие именно функции создаваемого в проекте продукта должны быть потрачены деньги проекта в первую очередь, а на какие функции денег может не хватить.  Его главная цель – за ограниченный бюджет проекта создать максимально ценный для клиента продукт. Для того, чтобы команда понимала, что делать в первую очередь, владелец продукта ведет Журнал продукта, в котором собраны все имеющиеся на данный момент требования  к создаваемому в проекте продукту, и расставляет по всем требованиям приоритеты. Для  расстановки приоритетов владелец продукта волен избрать тот подход, который ему больше нравится. Например, он может собирать совещание с заинтересованными в проекте сторонами и коллективно обсуждать требования, имеющиеся в Журнале продукта и присваивать им приоритеты. Но может расставлять приоритеты по требованиям к продукту и единолично. На тренингах по scrum меня часто спрашивают: "А может ли быть несколько владельцев продуктов, которые вместе будут отвечать за содержание журнала продукта и приоритеты в нем?" Мой ответ – нет. У семи нянек – журнал без глазу.  Обсуждать приоритеты можно в коллективе, но ответственность за наличие этих приоритетов в журнале продукта должен нести один человек.

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

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

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

Команда отвечает за выполнение запланированных на спринт задач и соответствие этих задач требованиям к ним. Одно из специфических требований к команде, работающей по скрам, – она должна быть кроссфункциональной, т.е. в ней должны быть представлены все специализации, которые нужны для получения продукта проекта. В Scrum Guide написано, что внутри команды могут быть специализации труда, но при этом ответственность за результат лежит на команде. Для меня это значит, что желательно, чтобы каждый участник мог выполнить задачу по смежной для него специальности. Многие команды спотыкаются, когда специалисты внутри команды имеют узкую специализацию, т.к. если один из них заболеет, то его заменить будет некем и спринт начинает буксовать. Еще одно требование к команде – она должна быть самоуправляемой. Это значит, что ни скрам-мастер, ни владелец продукта не должны диктовать команде, как выполнять работу и кто какие задачи в рамках спринта будет реализовывать.  Практикуется внутри команды самостоятельный выбор каждым участником тех задач, над которыми он будет работать в спринте. Иногда спрашивают: "А как нам работать по скрам, если в состав команды входят сотрудники разных подразделений?"  Я убежден в том, что для продуктивной работы сотрудников разных подразделений нужно объединить в команду, при этом желательно выделить их для работы над проектом на полный рабочий день. Никаких подразделений, иначе у вас не получится создать команду, в которой каждый участник понимает ответственность за результат и разделяет общую цель команды.

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

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

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

Надеюсь, у вас появились вопросы по ролевой модели в скрам, и я с удовольствием постараюсь на них ответить в комментариях к статье.

Продолжение следует…

Комментарии (0)
Войти как