Сравнение 5 фреймворков Agile Scaling: какой из них выбрать?

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

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

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

Когда следует масштабировать?

Существует ряд ключевых критериев, которым необходимо соответствовать, прежде чем вы задумаетесь о масштабировании:

Можете ли вы управлять разработкой только одной командой?

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

Ваша команда Agile?

Возможно, самым важным критерием является владение вашей командой подходами Agile. Если ваша команда не имеет опыта работы с Agile, то масштабирование создаст больше проблем.

Нужны ли методы разработки вашей команды в улучшении?

Если инженерные методы вашей команды неэффективны, масштабирование может не дать желаемых результатов. Такие практики, как правильная реализация DevOps и конвейера CI/CD, жизненно важны для согласованности между командами. Кроме того, без стандартизированной гарантии качества может быть сложно тестировать новые функции.

Предоставляет ли ваша команда интегрированные инкременты?

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

Выбор платформы масштабирования

Существует множество сред масштабирования Agile на выбор, но мы сосредоточимся на пяти наиболее широко используемых решениях: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale и Disciplined Agile (DA). . Я обнаружил, что это наиболее эффективные фреймворки, и их можно применять к целому ряду сценариев и организаций. Следующие разделы снабдят вас информацией, необходимой для того, чтобы сделать лучший выбор для вашего уникального контекста масштабирования.

1. Масштабируемая гибкая структура (SAFe)

SAFe — самый популярный фреймворк для гибкого масштабирования. Опрос 2021 года показал, что 37% практиков Agile используют его, в основном из-за его многочисленных конфигураций, каждая из которых ориентирована на потоки создания ценности и имеет четко определенные руководства и процедуры.

Поскольку SAFe используется для предоставления сложных решений, для которых требуется более 50 человек, он объединяет команды в agile-выпуски (ART). Чтобы синхронизировать команды в ART, SAFe использует итерации увеличения программы, аналогичные спринтам Scrum, и каждая итерация обычно длится от восьми до 12 недель. Такой подход позволяет менеджерам по продуктам сосредоточиться на общих целях и эффективно контролировать сложную дорожную карту продукта, не внося чрезмерных изменений.

SAFe основан на среде Scrum, но с парой ключевых отличий: внедрение SAFe происходит на уровне предприятия, а не на уровне команды; и в то время как Scrum дает владельцу продукта единоличное право расставлять приоритеты, SAFe поощряет более демократичный подход.

SAFe имеет четыре уровня реализации:

Необходимый БЕЗОПАСНЫЙ

Essential SAFe — это основа SAFe, которую необходимо освоить, прежде чем переходить к любой из последующих конфигураций. Он использует устоявшиеся роли Scrum, такие как Scrum-мастер, менеджер по продукту и владелец продукта, а также вводит новую роль: инженер по выпуску поездов. Этот человек выступает в роли лидера-слуги и тренера по ВРТ, помогая командам согласовывать свои цели. В ART может быть от пяти до 12 команд, каждая из которых способна предоставить комплексное решение.

Большое решение

Эта конфигурация находится поверх Essential SAFe и представляет концепцию, называемую «последовательность решений». Он используется при создании больших и сложных решений, требующих координации нескольких ART — потенциально сотен или даже тысяч людей, — работающих над одним и тем же потоком создания ценности. Например, если вы работаете в Microsoft и у вас есть три отдельные команды, занимающиеся программированием Excel, Word и PowerPoint, все они вносят свой вклад в один и тот же поток создания ценности: Microsoft Office.

портфолио

Портфель состоит из нескольких ART, работающих над разными потоками создания ценности. Продолжая пример с Microsoft: отдельные команды работают над продуктами Office, Skype или Xbox.

Полный БЕЗОПАСНЫЙ

Эта конфигурация объединяет все уровни — Essential, Large Solution и Portfolio — для координации управления коллективом в масштабах предприятия.

2. Нексус

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

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

3. Крупномасштабный Scrum (LeSS)

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

LeSS Huge использует клиентоориентированный подход к организации разработки. Для эффективного управления работой требуется, чтобы владелец продукта разделил высокоуровневый бэклог продукта на более мелкие «области бэклога» более гранулированных элементов, а затем отсортировал их дальше — по областям требований.

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

4. Скрам@Масштаб

Scrum@Scale — это расширение Scrum и, вероятно, самый простой для изучения и понимания фреймворк. Он масштабируется от одной команды до команды команд.

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

Уникальные роли в этой структуре включают мастера SoS, по сути, масштабированную версию мастера Scrum, и главного владельца продукта, который работает с владельцами продукта команды, чтобы сформировать совместный бэклог для SoS.

Scrum@Scale менее предписывающий, чем другие фреймворки, позволяя организациям масштабироваться в своем собственном темпе. Если количество команд продолжает расти, а собрания SoS становятся слишком большими, организации могут преобразовать структуру в Scrum of Scrum of Scrums (SoSoS).

5. Дисциплинированный Agile (DA)

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

Его можно применять на уровне группы разработчиков программного обеспечения или на уровне всего предприятия. Что касается последнего, набор инструментов DA определяет, какие бизнес-функции, такие как финансы, ИТ-операции и управление поставщиками, должны решать, и предлагает ряд вариантов для этого.

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

DA можно использовать поверх других фреймворков для дальнейшего масштабирования.

Выбирайте внимательно и масштабируйте медленно

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

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

Использовали ли вы эти фреймворки в своих действиях по масштабированию? Расскажите нам о своем опыте в разделе комментариев.