Масштабирование Agile для крупных команд

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

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

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

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

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

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

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

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

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

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

Ситуации

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

Функции

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

Истории

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

Задачи

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

Инициативы

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

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

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

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

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

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

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

Планирование

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

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

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

Зрение

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

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

Поиск

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

План 3-sprint

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

План Спринта

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

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

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

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

Чаты функций: где автономия соответствует выравниванию

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

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

Функции

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

Долг

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

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

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

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

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

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

При практике Гибкой в масштабе доверие является двусторонней улицей:

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

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

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

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

Следующие шаги

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

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

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