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

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

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

Блистательный эффект

Скрам-мастера – невоспетые мастера на все руки: посредники, помощники, советники и разрешители проблем.

Хороший Скрам-мастер делает работу над проектом намного проще.

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

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

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

Блистательный эффект

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

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

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

Пять Скрам-событий:

• спринт – общий цикл для остальных событий;

• планирование спринта – происходит в самом начале работы;

• ежедневная летучка (дейли Скрам) – происходит каждый день (без исключений);

• обзор итогов – проводится в конце спринта;

• ретроспектива – подводит итоги.

Спринт – жестко фиксированный по времени, от одной до четырех недель, временной период (time-box) для всех остальных Скрам-событий. Обычно команды выбирают длину спринта в две недели, но идеальной продолжительности нет – во всех вариантах будут присутствовать и плюсы, и минусы. Если есть сомнения, лучше начать с одно- или двухнедельного спринта и посмотреть, как пойдут дела.

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

Блистательный совет для сохранения времени

В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.

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

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

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

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

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

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

Блистательный пример

Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже принимают в этом участие.

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