Масштабирование Agile-команд

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

В Корпорации Майкрософт одна из таких организаций использует Agile для создания продуктов и служб, отправленных под брендом Azure DevOps. Эта группа содержит 35 функциональных команд, которые выпускают в производственную среду каждые три недели.

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

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

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

Чтобы управлять деликатным балансом между выравниванием и автономией, руководители DevOps должны определить таксономию, определить процесс планирования и использовать чаты функций.

Определение таксономии

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

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

Распространенная таксономия: эпики, фичи, истории и задачи.

Эпики

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

Функции

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

Истории

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

Tasks

Задачи определяют работу, необходимую для завершения истории.

Инициативы

Эта таксономия не является одноразмерной системой. Многие организации вводят уровень выше эпиков, называемый инициативами.

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

Линия автономии

После установки таксономии организация должна нарисовать линию автономии. Линия автономии — это точка, на которой владение уровнем передается от управления команде. Управление не вмешивается в уровни, принадлежащие команде.

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

В этом примере руководство не говорит команде, как разбивать истории, планировать спринты или выполнять работу.

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

Planning

Для масштабирования гибкого планирования команда должна иметь план для каждого уровня таксономии. Однако важно продолжать работу над планом и обновлять его. Этот процесс называется планированием скользящей волны.

План предоставляет руководство для фиксированного периода времени с ожидаемой калибровкой на регулярной основе. Например, 18-месячный план может быть откалиброван каждые шесть месяцев.

Вот пример методов планирования для каждого уровня таксономии: эпики, функции, истории, задачи.

Vision

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

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

Сезон

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

План из трёх спринтов

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

План Спринта

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

Линия автономии

В этом примере линия автономии проведена, чтобы показать, где команды обладают автономией в планировании.

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

Функциональные чаты: там, где автономия сочетается с согласованностью

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

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

Функции

Первый слайд описывает функции, которые команда активирует в следующих трех спринтах.

Долг

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

Проблемы и зависимости

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

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

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

Доверие: клей, который удерживает выравнивание и автономию вместе

При применении Agile-методологии в масштабных проектах доверие является двусторонним процессом.

• Управление должно доверять командам, чтобы сделать правильные вещи. Если управление не доверяет командам, они не будут предоставлять команде автономию.

• Команда получает доверие, последовательно предоставляя высококачественный код. Если команды не являются надежными, управление не даст им автономии.

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

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

Дальнейшие шаги

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

Узнайте о функциях Azure DevOps для управления портфелями и видимости между командами.

Корпорация Майкрософт является одной из крупнейших в мире компаний Agile. Узнайте больше о том, как корпорация Майкрософт масштабирует планирование DevOps.