Путь скрам-мастера. #ScrumMasterWay - Зузана Шохова

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

1. Роль и обязанности scrum-мастера

Роль scrum-мастера – одна из самых недооцененных в Scrum и Agile. Большинство начинающих команд не видят особого смысла в том, чтобы scrum-мастер работал на полной ставке, и, дабы «занять его работой», пытаются совместить эту должность с позицией разработчика или тестировщика. Это одна из самых распространенных ошибок в понимании роли scrum-мастера, свойственная большинству начинающих групп. Объясняется это примерно так: «Мы понимаем, что члены команды должны производить программный продукт, упорно трудиться. Они должны развивать кросс-функциональность и помогать друг другу. Должны сотрудничать. Мы также высоко оцениваем роль Владельца продукта, потому что этот человек определяет общее видение и согласовывает требования с клиентами. А как насчет scrum-мастера? Что делает он?» В таких условиях scrum-мастер часто превращается просто в секретаря – довольно скучная позиция, не правда ли? Он заботится о карточках на scrum-доске, сам устраняет все препятствия и близок к тому, чтобы начать готовить кофе для команды, пока она сосредоточена исключительно на работе. Знакомая ситуация?

Тогда продолжайте читать, потому что все описанное выше даже приблизительно не определяет основной роли scrum-мастера и его предназначения…

Другое весьма распространенное ошибочное отношение к роли scrum-мастера связано с тем, что кто-то берет ее на себя просто потому, что компании необходимо перейти на Scrum, – обычно такое происходит в крупных корпорациях. Там рассуждают примерно так: «Нам нужен scrum-мастер, чтобы воплощать Scrum, верно? Но мы не можем использовать для этого хорошего разработчика или тестировщика, потому что они должны заниматься программированием/тестированием». И scrum-мастером в таких случаях нередко становится какой-нибудь малоспособный, тихий человек, назначение которого scrum-мастером стало возможным лишь потому, что он не слишком хорош как разработчик.

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

Помните

Scrum-мастер – это не секретарь.

Scrum-мастер – это не «дополнительные расходы», а человек, создающий высокопроизводительную команду.

Scrum-мастер – это эксперт по agile- и scrum-мышлению, искренне верящий в то, что Agile и Scrum – верный путь к успеху.

Самоорганизующаяся команда

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

Самоорганизующаяся команда – это группа, которая сама умеет решать, как ей управляться с повседневными задачами. В Scrum это сводится к тому, «каким образом мы должны организовывать себя, чтобы определять цели спринта и спринт-бэклог на согласованном уровне качества в соответствии с определением «сделано»?». Иными словами, команда должна быть в состоянии решать, кому над какой задачей предстоит работать, как помогать друг другу, когда нужно будет учиться чему-то новому и как определять приоритеты повседневной работы при отсутствии внешнего авторитета.

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

Если некоторые члены команды чем-то недовольны, все должны быть готовы обсуждать это, понимая друг друга, и, как результат, изменять свой образ совместной работы и взаимопомощи. Наиболее важная характеристика – мировоззрение каждого отдельного человека. В хорошей команде демонстрируется подход «мы» вместо «я»: «Как я могу помочь команде это решить? Что я могу сделать для других?» вместо «Я ничего об этом не знаю. Это не моя проблема».

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

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

Группа индивидуумов

Джон расстроен. Снова и снова повторяется одна и та же проблема. Наконец он обращается к команде: «Я не получил никаких данных из системы! У вас есть идеи, как это можно исправить?»

Реакция команды:

Фред: «Да, это печально».

Жан [задумчиво]: «Слава богу, что я не выбрал сегодня эту задачу».

Рон: «Когда я вчера это пробовал, все было прекрасно».

Джейн: «Мне прошлой ночью помогла перезагрузка моего ПК».

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

Настоящая команда

Джон расстроен. Снова и снова повторяется одна и та же проблема. Наконец он обращается к команде: «Я не получил никаких данных из системы! У вас есть идеи, как это можно исправить?»

Реакция команды:

Жан: «Я могу взглянуть на Git[1], чтобы увидеть, вносил ли кто-то какие-нибудь изменения».

Джейн: «Я могу попробовать зайти в систему со своего компьютера, чтобы проверить, есть ли у меня та же проблема. Тогда мы сможем вместе проанализировать, что происходит».

Рон: «Это слишком часто стало нас беспокоить… Я, пожалуй, подумаю о том, как сделать, чтобы автоматизированные тесты выявляли проблему раньше».

Фред: «Ты прав, я помогу тебе с тестом».

Резюме. Команда обсуждает проблему, предлагая варианты ее решения. Все не только дают Джону советы, но готовы приложить усилия и помочь решить задачу. Они смотрят на проблему с командной точки зрения и высказывают идеи, которые помогут всей команде.

Конец ознакомительного фрагмента.

Сноски

1

Система управления версиями. – Прим. перев.