Фреймворк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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