Как корпорация Майкрософт планирует с помощью DevOps

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

Важные изменения

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

• Повышение культурного выравнивания и автономии.
• Изменение фокуса от отдельных лиц к командам.
• Создание новых стратегий планирования и обучения.
• Реализуйте модель с несколькими экипажами.
• Улучшение практики работоспособности кода.
• Повышение прозрачности и подотчетности.

Повышение культурного выравнивания и автономии

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

Двумя важными участник этого подхода являются выравнивание и автономия.

• Выравнивание происходит из верхней части вниз, чтобы обеспечить, чтобы отдельные лица и команды понимали, как их обязанности соответствуют более широким бизнес-целям.
• Автономия происходит снизу вверх, чтобы обеспечить влияние отдельных лиц и команд на повседневные действия и решения.

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

Изменение фокуса с отдельных лиц на команды

Корпорация Майкрософт упорядочивает людей и команды в три группы: PM, проектирование и проектирование.

• PM определяет, какие сборки Майкрософт и почему.
• Проектирование отвечает за проектирование того, что создает корпорация Майкрософт.
• Инженерия строит продукты и гарантирует их качество.

Команды Майкрософт имеют следующие ключевые характеристики:

• Кросс-дисциплинарные
• 10-12 человек
• Самостоятельное управление
• Очистить устав и цели в течение 12-18 месяцев
• Комнаты физической команды
• Собственное развертывание компонентов
• Собственные возможности в рабочей среде

Стремиться к вертикальным командам

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

На следующей схеме описывается разница между горизонтальными и вертикальными командами:

Разрешить самостоятельный выбор команд

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

Создание новых стратегий планирования и обучения

Дуайт Эйзенхауэр сказал: "Планы бесполезны, но планирование все". Планирование Майкрософт разбивается на следующую структуру:

• Спринты (3 недели)
• Планы (3 спринта)
• Сезоны (6 месяцев)
• Стратегии (12 месяцев)

Инженеры и команды в основном отвечают за спринты и планы. Руководство в первую очередь отвечает за сезоны и стратегии.

На следующей схеме показана стратегия планирования Майкрософт:

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

Реализация модели с несколькими экипажами

Предыдущие методы способствовали "прерыванию культуры" ошибок и инцидентов динамического сайта. Microsoft Teams придумали свой собственный способ обеспечить фокус и избежать отвлекающих факторов. Teams самостоятельно упорядочивает каждый спринт в два отдельных экипажа: функции (F-crew) и Customer (C-crew).

F-экипаж работает над совершенными функциями, и экипаж C занимается проблемами и прерываниями в реальном времени. Команда устанавливает вращающуюся частоту, которая позволяет членам планировать действия проще. Дополнительные сведения о модели с несколькими экипажами см. в статье "Сборка продуктивных", ориентированных на клиентов команд.

Улучшение практики работоспособности кода

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

Teams теперь реализует ограничение ошибок, вычисляемое формулой # of engineers x 5 = bug cap. Если количество ошибок команды превышает ограничение ошибок в конце спринта, они должны прекратить работу над новыми функциями и исправить ошибки, пока они не находятся под их крышкой. Команды теперь выплачивают долг ошибок по мере их использования.

Повышение прозрачности и подотчетности

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

Цели и ключевые результаты (OKR)

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

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

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

Внедрение платформы OKR может помочь командам работать лучше по следующим причинам:

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

ОКR могут существовать на разных уровнях продукта. Например, могут быть ОКров продукта верхнего уровня, ОКR уровня компонентов и ОКR уровня команды. Сохранение выравнивания OKR относительно легко, особенно если цели заданы сверху вниз. Любые конфликты, возникающие, являются ценными ранними индикаторами несоответствия организации.

Пример OKR

Цель: рост сильной и счастливой клиентской базы.

Ключевые результаты:

• Увеличьте оценку внешнего промоутера (NPS) с 21 до 35.
• Увеличьте удовлетворенность документацией с 55 до 65.
• Новый поток конвейера имеет оценку Apdex 0,9.
• Время очереди заданий составляет 5 секунд или меньше.

Дополнительные сведения о ОКR см. в разделе "Измерение бизнес-результатов" с помощью целей и ключевых результатов.

Выберите нужные метрики

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

• Изменение ежемесячных темпов роста внедрения
• Изменение производительности
• Изменение времени для обучения
• Изменение частоты инцидентов

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

• Точность исходных оценок
• Отработанные часы
• Строки кода
• Производительность команды
• Сгорание задач команды
• Скорость команды
• Количество найденных ошибок
• Покрытие кода

До гибкой и после гибкой разработки

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

Перед	После
4-6 месяцев вехи	3-недельные спринты
Горизонтальные команды	Вертикальные команды
Личные офисы	Комнаты группы и удаленные рабочие места
Циклы длительного планирования	Непрерывное планирование и обучение
PM, Dev и Test	PM, проектирование и инженерия
Ежегодное взаимодействие с клиентами	Постоянное взаимодействие с клиентами
Ветви возможностей	Все работают в главной ветви
20+ команды пользователей	8-12 человек команды
Схема секрета	Общедоступная общая стратегия
Задолженность по ошибке	Нулевой долг
Документы спецификации на 100 страниц	Спецификации PowerPoint
Частные репозитории	Открытый исходный код или InnerSource
Глубокая иерархия организации	Иерархия неструктурированных организаций
Номера установки определяют успешность	Удовлетворенность пользователей определяет успех
Функции отправки один раз в год	Функции доставки каждого спринта

Основные итоги

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