Глава 5. Просто лучшее: основы Скрама

Введение

Скрам (Scrum) стал популярен, потому что он работает. Правда, эта техника достигла нынешней известности не мгновенно. Скрам развился как технология разработки продуктов в середине 1980-х годов в Японии и был усовершенствован в США в 1990-х годах. Скрам пробовали, писали о нем – и статьи, и просто в блогах, – но наиболее важным было то, что в процессе этого он постоянно улучшался. В конечном итоге была получена какая-то критическая масса успешных проектов, и про Скрам заговорили.

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

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

Блистательная мысль

Нет плохого способа начать работать со Скрамом – главной ошибкой будет вообще не пробовать.

Рис. 5.1. Фреймворк Скрам

 

Рис. 5.2. Цикл спринта

 

Фреймворк

Как и все хорошие идеи, Скрам часто интерпретируется неверно. Чтобы снизить вероятность того, что идеи будут поняты неправильно, Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) создали «Руководство по Скраму» (Scrum Guide). Оно постоянно обновляется, доступно бесплатно на www.scrumguides.org и является единственным документом, объясняющим суть Скрама. Изменения вносятся редко; весь текст занимает 16 страниц вместе с содержанием и стоит того, чтобы с ним ознакомиться.

Скрам объединяет принципы «бережливого управления» и принципы Agile. Это не инструмент управления проектами, это принципы организации выпуска продукта – между этими двумя понятиями есть важные различия. Когда все идет хорошо, легко даже позабыть, что используется Скрам. Он предназначен только для поддержки хода работ, и об этом важно помнить.

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

• Теория: главное, знать фундаментальные принципы, не нужно особенно в нее углубляться.

• Роли команды: Владелец Продукта, Скрам-мастер и команда разработки: это основные роли.

• События: спринты, планирование спринтов, обзор итогов спринта и ретроспективное совещание со знаменитыми ежедневными дневными встречами в середине.

• Артефакты: журнал требований (бэклог) продукта, журнал требований спринта и другие.

Блистательное определение

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

Мы не могли бы дать лучшее определение.

Управляйте не временем, а приоритетами.

Деннис Уэйтли (мотивационный спикер)

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

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

Владелец продукта

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

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спринт

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

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