Менеджмент цифрового продукта. От идеи до идеала

Наиболее полное представление о Scrum можно получить из книги Джефа Сазерленда «Scrum: The Art of Doing Twice the Work in Half the Time» (дословно: «Scrum: искусство сделать вдвое больше за половину времени). Официальное название книги в России – «Scrum: Революционный метод управления проектами», однако, несмотря на возможную коммерческую эффективность, этот перевод содержит ряд неточностей: Scrum HE революционный HE метод HE управления HE проектами.

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

➠ Scrum – НЕ метод. Scrum – это фреймворк. В отличие от метода, фреймворк не содержит конкретных алгоритмов для решения задач, а предлагает набор рамок – правил и ограничений, – в которых команда самостоятельно разрабатывает и внедряет методы.

➠ Scrum НЕ для управления проектами. Как уже говорилось ранее, Scrum ориентирован на продуктовый подход; он следует итеративной, адаптивной инкрементальной поставке ценности.

Scrum является эмпирическим процессом управления, что означает, что знания и понимание развиваются на основе опыта и наблюдений. Этот подход основывается на трех основных столпах: прозрачности (transparency), инспектировании (inspection) и адаптации (adaptation).

➠ Прозрачность требует, чтобы все аспекты работы были видимы для тех, кто несет ответственность за результат.

➠ Инспектирование подразумевает регулярное наблюдение за продуктом и процессом работы для определения того, соответствуют ли они ожиданиям и целям.

➠ Адаптация означает изменение подхода или процесса на основе этих наблюдений для оптимизации результатов.

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

Scrum регулярно обновляется, его актуальное описание можно найти на сайте scrumguides.org. Могу сказать, что я не часто обращался к руководству, так сам по себе фреймворк сложно представить без множества лучших практик, которые стали неотъемлемой частью Scrum-процесса. Поэтому мы рассмотрим роли, события и артефакты Scrum не только по руководству, но и в отношении лучших практик, ставших промышленным стандартом, и множество личных историй и примеров.

3.2.1. Роли в Scrum

В Scrum три роли:

➠ Scrum-мастер (Scrum master, SM)

➠ Владелец продукта (Product owner, РО)

➠ Команда разработки (Development team, DT), вся команда – одна роль.

Вместе они составляют Scrum-команду (Scrum team, ST).

Мы привыкли к тому, что в любом процессе всегда есть две роли: заказчик – исполнитель, начальник – подчиненный. Почему же в Scrum именно три роли, а не две? Давайте вспомним классический треугольник компромиссов: деньги – скорость – качество. Если мы хотим после старта разработки «натянуть» одну вершину, то страдают две остальные (рис. 3.8).

Если в процессе участвуют две роли, значит, кто-то должен одновременно отвечать за две вершины, например, исполнитель – за скорость и качество, что порождает внутренний конфликт. Три роли позволяют создать натяжение, где каждому участнику не нужно бежать в обе стороны (рис. 3.9).

Рис. 3.8. Классический треугольник компромиссов

Рис. 3.9. Треугольник компромиссов, адаптированный для Scrum

Команда разработки (DT) фокусируется на качестве. Владелец продукта (РО) – на возвратности инвестиций (Return of Investments, ROI). Так как продуктовый процесс не ограничен во времени, нет фиксированного бюджета и РО нужно следить, чтобы каждый спринт был максимально эффективным вложением.

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

3.2.1.1. Scrum-команда

Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

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

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