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

3.3.8.1. Модель Spotify

Модель Spotify – это гибкая модель организации работы, которая была разработана и применена в компании Spotify, известной своим музыкальным стриминговым сервисом (рис. 3.26). Модель Spotify не является формальным фреймворком, а скорее набором практик и принципов, которые можно использовать для создания гибкой и инновационной культуры в организации.

Без сомнения, модель Spotify – одна из самых часто упоминаемых в процессе масштабирования гибких подходов. Многие элементы, упомянутые в их обучающем видео Spotify Engineering Culture в 2014 году, входят в состав проприетарных Agile-фреймворков[50] крупнейших компаний.

Рис. 3.26. Модель Spotify

Модель Spotify основана на концепции сквадов (squads, часто говорят отряды) – маленьких кросс-функциональных и самоорганизованных команд, которые работают над одной функциональностью или частью продукта. Сквады объединяются в трайбы – большие группы, которые работают над одним доменом или областью продукта. Также в модели Spotify есть другие структуры, такие как:

➠ Отделение (chapter, часто говорят «чаптер») – это группа людей с одинаковым набором навыков или функций, например фронтенд-разработчики, тестировщики, дизайнеры и т. д. Отделение формируется внутри племени, которое представляет собой большую группу людей, работающих над одним продуктом или доменом. Цель отделения – развивать навыки его членов и поддерживать обмен информацией и последовательность. Отделение возглавляет лидер (также известный как чаптерлид), который является линейным руководителем членов отделения и поддерживает их в личностном росте и решении конкретных задач. Отделение регулярно собирается для обсуждения лучших практик, стандартов и общих проблем. Часто отделения называют центрами практик или центрами компетенции[51].

➠ Гильдия (guild) – более широкая и неформальная группа людей, которые разделяют общий интерес или страсть к какой-то теме или области знания. Гильдии могут включать в себя членов разных отрядов, трайбов и отделений, а также других сотрудников компании. Например, гильдия пользовательского интерфейса может включать дизайнеров и фронтенд-разработчиков. Гильдии организуют регулярные или спонтанные встречи, на которых обмениваются идеями, опытом и лучшими практиками, а также проводят обучения, ворк-шопы и хакатоны. Гильдии помогают распространять знания и инновации по всей компании, а также повышать мотивацию и вовлеченность сотрудников.

Еще один компонент, который нельзя не упомянуть, – это механизм поезда поставок (release train). Он позволяет нескольким командам работать над одним продуктом, чтобы при слиянии инкремент одной команды не ломал инкременты других. Производится ритмичное тестирование поставки релиз-кандидата по расписанию, по аналогии с поездом, который отходит в определенное время. Если инкремент не успевает на поезд, то не вливается в поставку, а если не проходит тестирование (ломает другие инкременты), то не вливается в поставку или вливается с отключенным feature-toggle (в отключенном состоянии при помощи механизма feature-toggling, описанном в 2.1.7).

3.3.8.2. Scaled Agile Framework

Scaled Agile Framework (SAFe)[52] – это гибкий фреймворк для разработки и поставки продуктов и решений, который позволяет масштабировать Agile-подходы на уровне предприятия. SAFe основан на принципах Lean и Agile, а также включает в себя четыре уровня: командный, программный, большого решения и портфельный. SAFe предлагает ряд ролей, артефактов и процессов, которые помогают координировать и синхронизировать работу множества команд, работающих над одним или несколькими продуктами или решениями. Он также поддерживает различные конфигурации в зависимости от размера и сложности организации и продукта.

SAFe тоже имеет в своем составе практику поездов поставок, для этого организуется синхронизация спринтов.

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

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

Large Scale Scrum (LeSS) – это гибкий фреймворк для масштабирования Scrum на уровне нескольких команд, работающих над одним продуктом. LeSS стремится сохранить простоту и эффективность Scrum, а также избегать излишней стандартизации и бюрократии. LeSS основан на том, что один продукт имеет один продуктовый бэклог, одного владельца продукта и одно определение завершенности. Он также предполагает, что команды координируют свою работу через совместное планирование, демонстрацию и ретроспективу, а также через общие роли, такие как Scrum-мастер и коуч. LeSS имеет две конфигурации: LeSS и LeSS Huge, которые зависят от числа команд.

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

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

Многие считают SAFe противоположностью LeSS из-за фокуса второго на минимальность управляющих ролей.

3.3.8.3. Scrum@Scale

Scrum@Scale – фреймворк, первично разработанный Джефом Сазерлендом, а значит, он идеально работает со Scrum (рис. 3.27). Scrum@Scale, по мнению экспертов, обладает одним из лучших балансов в представленности непроизводящих ролей.

До определенного уровня новые роли не выделяются, и ответственность за вопросы масштаба ложится на Scrum-мастеров и владельцев продукта. Одна из идей – выстраивание организации по фрактальному принципу. Каждые пять команд объединяются в Scrum of Scrums (SoS), которые, в свою очередь, могут соединяться в SoSoS. В каждом SoS появляются свои события, например масштабированный дневной Scrum (scaled daily Scrum), на котором присутствуют представители команд для синхронизации.

Рис. 3.27. Модель Scrum@Scale

Согласно некоторым исследованиям, Scrum@Scale занимает пятое место в мире по популярности, но не очень распространен в России. Хотя практика Scrum of Scrums, согласно исследованиям, в России достаточно распространена.

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