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

3.2. Scrum

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

Scrum в переводе с английского – схватка вокруг мяча. Термин, применяемый в регби, означает прием, когда команда объединяется и наваливается на противников. Смысл такой аналогии в том, что команда разработчиков «наваливается» на проблему для достижения цели спринта, в отличие от водопадного подхода, где каждый в рамках своей выделенной роли выполняет определенный этап обработки артефакта.

Наиболее полное представление о 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 не только по руководству, но и в отношении лучших практик, ставших промышленным стандартом, и множество личных историй и примеров.

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть] и отвечает за:

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

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

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

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

Т-образные (англ. T-shaped, в форме буквы «Т») специалисты названы так по способу формирования компетенций и представляют собой комбинацию специалистов широкого профиля (dash-shape, или тиреобразные) и узких специалистов глубокого профиля (I-shape, или 1-образные). Т-образные специалисты глубоко разбираются в одной экспертизе, но при этом на базовом уровне разбираются в смежных (рис. 3.11).

Рис. 3.11. Способы формирования компетенций. Т-, I– и «-»-образные специалисты

Наличие таких специалистов в команде позволяет убрать бутылочные горлышки и снизить так называемый фактор автобуса[42]42
  Фактор автобуса (англ, bus factor) – количество разработчиков, при потере которых (в оригинале «попадании под автобус») поставка не может быть выполнена.


[Закрыть].

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

Некоторые компании, в которых мне доводилось работать, поощряли развитие разработчиков в сторону Т-образности. Известная практика – создание звездной карты.

Рис. 3.12. Звездная карта

Звездная карта (рис. 3.12) – это простой инструмент, представляющий собой матрицу, в которой в пересечении «сотрудник – экспертиза» устанавливается звездочка, если сотрудник «звезда» в этой экспертизе, и точка, если может подменить «звездного» сотрудника, который по какой-то причине выпал. Звездная карта позволяет видеть провалы в экспертизах и риски возникновения бутылочного горлышка в случае незаменимости «звезды». Для минимизации риска «автобуса» можно поощрять сотрудников к развитию горизонтальных компетенций, например, оплачивая обучение. Если сотрудник хочет изучить что-то не по профилю, в ячейке ставится значок «книга».

Долгое время рынок труда в IT не поощрял многопрофильность. Это накладывало ограничение на желание разработчиков развиваться в смежных сферах. Например, фронтенд-разработчик не хотел развиваться в бэкенде, так как это не увеличивало его стоимость на рынке.

Сейчас, с развитием Agile, растет потребность в фулстек-разработчиках (от англ, full stack, полный стек[43]43
  Технологический стек – набор технологий, используемых ПО и для разработки и поддержки ПО. Сюда входят базы данных, фронтенд-фреймворки, инструменты разработки, мониторинга, анализа данных, внешние API и пр.


[Закрыть]), и вакансий с каждым годом становится все больше.

Расширение команды увеличивает время на синхронизацию и ответственность каждого участника.

Согласно закону Меткалфа[44]44
  * [43] Закон Меткалфа гласит, что полезность сети пропорциональна половине квадрата (п²/2) численности пользователей этой сети.


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

Чем больше команда, тем меньше ощущение личного вклада в результат, а следовательно, и ответственность становится все менее очевидной.

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

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

Изменение состава команды нарушает внутренние равновесие и перезапускает процесс ее формирования.

Рис. 3.13. Стадии формирования групп по Брюсу Такману

Брюс Такман в 1961 году предложил модель групповой динамики, согласно которой команда проходит четыре стадии формирования (рис. 3.13):

➠ формирование (forming),

➠ шторм (storming),

➠ нормирование (norming),

➠ производительность (performing).

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

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

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

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

➠ разработку и детальное донесение цели продукта;

➠ разработку и ясное донесение элементов продуктового бэк-лога;

➠ приоритизацию элементов продуктового бэклога;

➠ обеспечение доступности, прозрачности и понятности продуктового бэклога.

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

Плохо, когда владелец продукта:

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

➠ Перегружен работой: будет терять контекст.

➠ Совмещает: не будет нести ответственность в трудной ситуации.

➠ Работает удаленно: будет недоступен в срочной ситуации и часто неправильно понят.

➠ Прокси: будет задерживать и искажать сигнал от реального РО.

➠ Скрытный: команде будет трудно понять, как сделать, если непонятно, зачем.

➠ Комитет: решения будут затягиваться.

➠ Не заинтересован: команда будет демотивирована бесполезным трудом.

➠ Боится: страх парализует и заставляет имитировать работу.

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

➠ развивает команду в сторону самоорганизации и кросс-функциональности;

➠ помогает увеличивать производительность – поставлять как можно больше максимально ценных элементов продуктового инкремента каждый спринт;

➠ убирает препятствия в прогрессе команды;

➠ фасилитирует события Scrum для регулярного увеличения их эффективности.

Scrum-мастер помогает владельцу продукта ⁄ Scrum-команде:

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

➠ эффективно действовать в комплексном мире (см. п. З.1.З.);

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

➠ организовать взаимодействие со стейкхолдерами, фасилитировать встречи.

На уровне организации Scrum-мастер:

➠ возглавляет и активно участвует во внедрении Scrum;

➠ участвует в планировании мероприятий по внедрению;

➠ помогает стейкхолдерам осознать и внедрить эмпирический процесс для комплексного мира;

➠ убирает препятствия между стейкхолдерами и Scrum-командой.

Важно добавить, что Scrum-мастер создает эффективную здоровую среду взаимного профессионального уважения и самостоятельности. Он выступает в роли третейского судьи для команды разработки и владельца продукта. Это позволяет добиться состояния справедливости, когда владелец продукта не «продавливает» команду, а команда не «продавливает» ПО.

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

Плохо, если Scrum-мастер:

➠ Проджект-менеджер: это противоречие на уровне операционных окружений по модели «Киневин», рассмотренной в п. 3.1.3.

➠ Прокси: чью бы волю ни выполнял – РО, СТО, SH[45]45
  SH – сокращение от англ, stakeholder – стейкхолдер.


[Закрыть], – в команде образуется несправедливый перекос;

➠ Частичный: SM, который работает на две и более команды, по-настоящему не болеет ни за одну из них;

➠ Нянька: потакая капризам команды, убивает в них самостоятельность;

➠ Трусливый: боится настоять на правильном процессе, из-за чего Scrum превратиться в Scream.