Многие разработчики думают, что скрам-мастер — это просто бесполезный человек, который занимает место в команде и ничего нужного не делает. Да ещё получает за это деньги, когда на них можно было бы нанять ещё одного разработчика.

Казалось бы, при создании проекта всегда есть такие роли, как владелец продукта (Product Owner, PO) и менеджер проекта (Project manager, PM), им и карты в руки. Иногда непонимание роли скрам-мастера приводит к тому, что существующие менеджеры считают, что это их роль.

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

Владелец продукта формирует бизнес-задачи. Он исходит из требований заказчика. Ему нужно, чтобы разработчики сделали всё, что он запланировал в соответствии с заказом клиента. При этом он не особо вдаётся в какие-то технические вопросы и проблемы разработки. Для него главное — выдать задачи и побыстрее их реализовать.

Менеджер проекта, который анализирует идеи и ставит общие задачи, тоже в большей степени вовлечён в бизнес-сторону проекта, при этом технического бэкграунда ему, как правило, не хватает. Он недосконально представляет себе процесс разработки и может не знать или не учитывать каких-то возможностей команды.

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

Участие PM должно быть подобно участию PO, который отстаивает потребности клиентов. Когда вовлечённость переходит в постановку задач для команды — возникает проблема. Даже при самых благих намерениях он склонен скрывать трудности: ошибки, изменения и переносы сроков. И это ведёт к нарушению графика выполнения, конфликтам и ухудшению качества. Это рецепт провала.

Я ведущий инженер по тестированию в Центре экспертизы качества программного обеспечения Газпромбанка и выполняю роль скрам-мастера в нашей команде. Поделюсь своим взглядом на эту роль и попробую объяснить, почему скрам-мастер нужен команде.

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

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

Кто такой скрам-мастер?

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

Скрам-мастер не только помогает создать Scrum и следит за ходом работ, но и обеспечивает членам команды возможность решать вопросы и проблемы, которые могут возникнуть в процессе. Он должен уметь мотивировать и вдохновлять, разгребать конфликты, выстраивать коммуникации между коллегами. И всё это он делает не на словах, а на деле, постоянно находясь в состоянии рабочей готовности. Именно поэтому скрам-мастер нуждается в гибких навыках (Soft Skills), которые необходимы для общения с членами команды и другими сотрудниками организации. Скрам-мастер несёт ответственность за помощь своим командам в достижении успеха, а это часто означает оказание им помощи в группах или один на один. Он может содействовать проведению упражнений, давать указания или помогать людям самостоятельно прийти к выводам.

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

Как это работает

В начале работы над проектом или продуктом PO создаёт максимально полный список всех требований (бэклог), предъявляемых к продукту, расставляя их по приоритетам. Бэклог может развиваться и изменяться на протяжении всего срока реализации проекта. Затем каждый пункт оценивается по сложности и необходимым затратам, которые потребуются для его выполнения.

PO берёт в бэклог очень много задач, тем самым раздувая его, и в конце команда не может выполнить то, что запланировали. Мы в нашей команде неоднократно брали на себя большие задачи. Эти задачи были недостаточно декомпозированы. Тем самым при разработке возникала куча вопросов.

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

Отсутствовало какое-либо взаимоотношение внутри команды. Не было эмпатии. Бизнес что-то говорил, аналитики анализировали, выдавали эту историю разработчикам, но при этом не было вовлечённости всей команды.

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

Мы стали вести работу короткими циклами (спринтами). Это определённое время (обычно не превышающее месяца, у нас это две недели) для выполнения части заданий. Каждая крупная задача декомпозируется на несколько мелких. Это позволяет в чётко обозначенные и непродолжительные периоды времени добиваться конкретных целей. Более того, каждый спринт теперь планируется PO совместно с командой разработчиков.

Но чтобы этого добиться, понадобился скрам-мастер, который отвечает за то, чтобы поставленные задачи были максимально прозрачными в течение всего проекта, причём для всех. В том числе он помогает PO чётко определить для себя цели проекта и донести их до всей команды. В какой-то степени в нашей команде скрам-мастер выполняет и функции PM.

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

К примеру, сейчас у нас в банке запускается программа финансирования индивидуального жилищного строительства, и под неё дорабатывается система, создаются новые экранные формы. Задача делится на этапы. Например, мы разработали одну экранную форму. Её нужно будет протестировать и зафиксировать. Соответственно, здесь уже подключаются тестировщики и разработчики. Чтобы далее продумать процесс, не сломать что-либо и добавить новый функционал, бизнес-аналитики разрабатывают следующую спецификацию для разработчиков для второго этапа. Т. е. делим задачу на более мелкие, которые последовательно решаем.

Мы стали проводить ежедневные короткие встречи, где команда обсуждает, какие есть проблемы и как они их решают. И это важно, поскольку всегда есть люди, которые молчат, а есть те, которые думают, что так как PO здесь главный, то надо кровь из носу всё сделать, и нечего тут обсуждать.

Скрам-мастер выполняет роль модератора. Он, например, говорит: «Ребята, у нас запланирован пул задач. Почему мы здесь встали? Какие у вас проблемы?»

Кроме этого, скрам-мастер проводит и другие встречи — как с командой, так и с представителями других подразделений. Именно такой специалист организует обсуждение интеграционных взаимодействий разных сервисов, когда, например, нужно участие двух команд.

Смысл работы скрам-мастера не в том, что он управляет разработкой, по сути, заменяя PM, а в том, что следит за задачами и временем их выполнения. Он максимально нейтрален, он не выбирает ни одну из сторон. Он просто спрашивает: «Почему? Зачем? В чём проблема?» И решает, обсуждать ли это всей командой или это можно отдельно проговорить в другом месте. Сам он не принимает решения, у него нет полномочий для этого, но он выявляет суть проблемы и обеспечивает её обсуждение, чтобы решить её совместно. Он занимается мотивацией сотрудников, а иногда даже выполняет роль ментора, который передаёт им свой опыт и направляет членов команды по оптимальному пути.

Кто может быть скрам-мастером и как это организовано у нас

Скрам-мастером может быть любой человек из команды. Это может быть либо один из разработчиков, либо аналитик. Может даже тестировщик или релиз-менеджер, который тоже участвует в работе команды. Т. е. один из тех, кто заинтересован в успехе выполнения проекта. Либо это может быть отдельный специалист, которому платят деньги за выполнение этой функции, который отучился и получил кучу сертификатов именно по этой специальности. В нашей организации этим занимаюсь я, при том что основная моя роль — это QA, а на эту задачу мне выделяется 10 % рабочего времени. В других командах скрам-мастером может быть, например, аналитик. Главное — это уметь общаться с командой, а если этот навык не отлажен, то ему надо научиться.

Как это у нас организовано. Поскольку спринт у нас двухнедельный, то в первую неделю я не пытаюсь вмешиваться в процесс. Но если у кого-то из команды возникают вопросы, то они обращаются ко мне. А во вторую неделю я уже сам прихожу к команде и спрашиваю: «Как у вас дела по задачам? Что движется? Где мы стоим?» Тогда я узнаю, как прошла предыдущая неделя, какие у нас успехи и сложности. Затем мы сообща кратко обсуждаем, как решать возникающие проблемы.

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

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

Каков результат внедрения функционала скрам-мастера

Как было раньше: решением всех проблем занимался Lead команды. Выдавалась задача, и команды работали над её выполнением (аналитики, разработчики, тестировщики). В каждой команде — свой Lead. Между командами отсутствовала прозрачность процессов, поэтому не развивались ответственность и коммуникации, а это ограничивало рост и результат команды.

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

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

Раньше люди из разных отделов либо не общались, либо использовалась переписка. Сейчас за организацию встреч между командами отвечаю я как скрам-мастер. Если происходят какие-то негативные ситуации в команде, то я всегда знаю об этом, поскольку именно ко мне обращаются для разрешения конфликта, и принимаю соответствующие меры. Цель скрам-мастера — не избавиться от конфликтов, поскольку это невозможно, а нейтрализовать их, общаясь со всеми. В его функции входит сделать так, чтобы команда жила единым организмом. Чтобы не было тех, кого надо тянуть за уши и говорить: «Почему ты не работал?» Сейчас у нас это исключено.

У нас есть команда, у нас есть общая цель. Команда научилась сама планировать, она знает свои возможности и свой предел. Мы стали более осознанными, что ли. Команда научилась сама планировать свою работу, она знает свои силы и свои возможности. Теперь мы берём в работу такой пул задач, который мы в силах выполнить с определёнными понятными рисками. Всё это дало нам новое ощущение жизни каждого из нас именно в команде.

Какая польза для организации от появления скрам-мастера

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

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

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

Итак, ответ на вопрос «Зачем нужен скрам-мастер в команде разработчиков?» очевиден: чтобы обеспечить высокую эффективность проекта. Сегодня скрам-мастер — это специалист, без которого сложно представить работу профессиональной команды. Важно помнить, что его работа — это не просто выполнение всего объёма задач, но и следование принятой стратегии, контроль баланса сил и интересов, а в конечном счёте — ответственность за результат.