Скрам-мастер: что это за специалист и как им стать?

При старте команд нужно уделить особое внимание организационной структуре

Очевидно, что организационная структура значительно влияет на успех команд. Поэтому прежде, чем запускать «пилот» по Скраму, нужно подготовить под него соответствующую структуру.

Ниже вы найдете мой обычный чек-лист, который помогает оценить готовность компании к Скраму:

Ежедневные Скрамы

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

• Что было сделано со времени прошлой встречи?
• Что планируется сделать до следующей встречи?
• Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.
Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

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

На чем стоит Scrum: роли, элементы и другое

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

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

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

Роли в Scrum

В Scrum всего 3 роли:

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

1. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
2. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

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

Sprint Backlog

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

Sprint Goal

Краткое описание цели, ради которой выполняется спринт. Целевое оформление спринта помогает команде в принятии обоснованных решений. Артефакт несет неоценимую помощь в пользу проекта, если команда находит альтернативные пути выполнения задачи и имеет право самостоятельно принимать подобные решения. Для осознанности таких решений и определяется цель спринта. 

Sprint Burndown Chart

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

Ритуалы (процессы) в Скрам

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

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

• Что я делал вчера?
• Чем я занимаюсь сегодня?
• Какие есть проблемы?

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

Sprint Review

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

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

• Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
• Какие проблемы мешают выполнять обязательства, возложенные на команду?
• Как еще лучше работать и взаимодействовать с Product Owner’ом?
• Какие ошибки допускаются в команде и почему это происходит?

Scrum: определение и краткая история

Понятие «scrum» («скрам») впервые появилось в середине 80-х годов ХХ века в работах японских ученых Икуджиро Нонаки и Хиротаки Такеучи, когда они говорили об успехе проектов, в разработке которых участвовали небольшие команды без жесткой специализации. Эти команды они сравнивали с конструкцией схватки (от англ. «scrum») в регби, назначающейся судьей при остановке игры или при нарушении правил.

Позже, в 1993 году американский программист Джеф Сазерленд применил этот подход, когда разрабатывал методологию для компании «Easel» (детально об этом можно прочитать в его книге «Scrum – революционный метод управления проектами»). Тогда он и назвал его официально «Скрам». А два года спустя разработчик и консультант по разработке ПО Кен Швабер формализовал этот процесс применительно ко всей индустрии вообще.

В 1995 году на конференции «Объектно-ориентированные системы, языки и приложения для программирования» Швабер указал, что основой Scrum-методологии является итеративная разработка, а сама она определяет несколько характеристик при работе с проектами:

• Правила планирования и управления списком требований к разрабатываемому продукту
• Правила планирования итераций
• Правила взаимодействия между членами проектной команды
• Правила анализа и корректировки процесса разработки

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

Каждая итерация проекта может быть представлена в виде цепочки: планирование – фиксирование – реализация – анализ. Благодаря фиксированным требованиям к одной итерации, как к фазе выполнения проекта, а также возможности менять длину итераций, можно эффективно управлять балансом гибкости и планируемости разработок.

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

Планирование Спринта

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

• Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
• Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

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

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

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

Как сделать «пилоты» более успешными

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

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

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

Для визуализации agile-подходов используют доски: физические и электронные

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

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story)

Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager:

Описание каждой истории должно включать в себя набор обязательных полей, необходимых для дальнейшей работы над проектом:

Важность (Importance). Степень важности задачи по мнению владельца продукта

Описывается произвольным числом.

Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах.

Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи.

Помимо этих обязательных полей, при необходимости могут быть добавлены дополнительные:

• Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
• Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
• Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
• ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Шаг 3. Работа над спринтом. Scrum meetings

После того, как определены актуальные для данного спринта пользовательские истории, начинается процесс .

Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово»

Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта:

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

Результатом каждого совещания также является burndown-диаграмма. По оси X на ней откладываются дни работы над спринтом, а по оси Y — общее количество story points для данного спринта. После завершения задачи, требовавшей определенного количества story points для ее решения, можно отметить на диаграмме точку, в которой на данный момент находится проект. Пример такой диаграммы, построенной в JIRA, приведен ниже:

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