Скрам-мастер

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

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

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

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

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

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

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

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

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

Команда разработки

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

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

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

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

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

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

Ключевые Скрам-события

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

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

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

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

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

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

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

Спринт

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

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

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

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

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