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

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

Основополагающие изменения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример OKR

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

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

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

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

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

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

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

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

• Точность исходных оценок
• Отработанные часы
• Строки кода
• Емкость команды
• Диаграмма сгорания команды
• Скорость команды
• Количество обнаруженных ошибок
• Покрытие кода

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

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

Основные выводы

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