Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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