В 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-команда кросс-функциональна. Это означает, что участники имеют все необходимые экспертизы, чтобы создавать дополнительную ценность каждый спринт.

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

Scrum-команда полностью самостоятельна и наделена полной властью для достижения целей спринта, а следовательно, самостоятельно несет ответственность за взаимодействие со стейкхолдерами, сопровождение, операционную деятельность, исследования, R&D и все остальное, что может понадобиться в процессе.

ST наделена всеми полномочиями на управление собственной структурой и процессами.

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

3.2.1.2. Лучшие практики организации Scrum-команд

Самостоятельность

Любые внешние зависимости снижают ответственность за поставку. Наверное, самой популярной причиной срывов сроков поставки или нежелания их называть можно считать внешние обстоятельства:

➠ Ждем, пока юристы согласуют формулировку.

➠ Ждем, пока другая команда развернет обновление API.

➠ Ждем, пока Scrum-мастер перенесет истории из продуктового бэклога в бэклог спринта и т. д.

Несколько практик по работе с внешними зависимостями:

➠ Максимальная автономность. Если в команде регулярно возникает потребность в доработке артефакта внешними участниками, необходимо развить внутренние компетенции и получить соответствующие полномочия. Например, для доступа к определенной системе разработчик получает определенные допуски или юрист на время становится частью команды и отвечает вместе со всеми за соблюдения сроков.

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

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

➠ Выявление и регулярное устранение внешних зависимостей. На определенном масштабе, когда команд становится много, требуется настроить процесс работы с зависимостями. Создается доска зависимостей (dependency board), команды назначают друг другу задачи по устранению зависимостей, и зависимости устраняются, часто с повышенным приоритетом.

Вертикальная интеграция

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

➠ Бизнес-блок. Компания подразделяется на несколько бизнес-блоков. Каждый из них автономен с точки зрения внутренней экономики, имеет обособленный P&L, за который отвечает руководитель блока.

➠ Трайб (tribe, иногда племя) – совокупность отрядов, сфокусированных вокруг одного продукта или портфеля родственных продуктов. Руководитель трайба отвечает за финансовый эффект продуктов портфеля трайба.

➠ Отряд – минимальная автономная команда (например, Scrum-команда), разрабатывающая продукт или компонент. Владелец продукта отвечает за возврат инвестиций в разработку продукта.

Приведенная структура может отличаться от компании к компании, но главная идея в том, что разделение бизнеса на несколько автономных зарабатывающих сущностей диверсифицирует риски, делая систему антихрупкой. Каждая минимальная команда (отряд), по сути, представляет собой маленький бизнес в бизнесе.

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

Хороший подход, когда продуктовая команда самостоятельно отвечает за качество на уровне определения завершенности (Definition of Done, DoD).

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

Помимо таких достаточно простых примеров, есть менее очевидные, например команда, образованная вокруг систем, заново используемых другими продуктами, таких как единая точка входа (single sign-on, SSO), рекомендательная система или система мониторинга.

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

Коллективное владение системой

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

Практика коллективного владения системой основана на практике коллективного владения кодом из экстремального программирования (extreme programming, ХР).

Роль делегата может возникать как дополнительная роль у уже существующего участника команды; при увеличении нагрузки может быть выделен отдельный человек или даже несколько.

Рис. 3.10. Виртуальная команда

Доработки системы инициируются владельцами продукта, делегаты осуществляют доработку системы, а развертывание начинается с проверки кода несколькими делегатами.

С примерами реализации практики коллективного владения системой можно ознакомиться в табл. 3.3.

Табл. 3.3. Сравнение коллективного и централизованного владения системами

* Дашборд (англ, dashboard) – это интерактивная панель, на которой отображаются все метрики из гипотез жизнеспособности продукта в режиме реального времени.

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

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

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

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

Команда разработки (development team, DT), или разработчики – это часть Scrum-команды, которая берет на себя обязательство поставлять полезный инкремент каждый спринт. Команда обладает всеми необходимыми навыками в операционном домене[41] и отвечает за:

➠ формирование бэклога спринта и плана достижения целей спринта;

➠ развитие качества путем соблюдения и дополнения определения завершенности (DoD);

➠ ежедневную адаптацию плана для достижения цели спринта;

➠ профессионализм друг перед другом.