Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - читать онлайн книгу. Автор: Роб Коул, Эдвард Скотчер cтр.№ 19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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