UncategorizedгаджетыНовостиразработчиктехнология

«Долг» как путеводитель по Agile: технический долг

Ключевые выводы

  • Такие фреймворки, как Scrum @ scale, могут помочь вам ориентироваться в гибкой трансформации, предоставляя целостную структуру, которая выявляет проблемы и возможности для улучшений. Однако рамки не дают понимания того, что вызывает боли и как их устранить.
  • Используйте свою интуицию, чтобы понять первопричины, и вы, вероятно, обнаружите, что в них есть закономерность, которая вращается вокруг долга: устаревшие технологии и технический долг не только ограничивают технические возможности, но и потребляют умственные ресурсы и ограничивают способность мыслить. из коробки.
  • Если у вас есть команда, которая вынуждена разрабатывать новые решения для вашего бизнеса, которые они не могут предоставить, потому что они тонут в работе старых технологий, рассмотрите возможность временного разделения команды и разделения ответственности за Dev и Ops между командами, чтобы позволить инженерам фокус.
  • Когда вам нужно, чтобы ваши команды активизировались и взяли на себя ответственность за качество своих продуктов, например, увеличили зрелость их выпусков, подумайте об установке фреймворка, который дает командам свободу решать, как улучшить структурированный способ. Убедитесь, что у команд есть стимулы для работы над улучшениями, и вдохновите на то, как улучшить свои компетенции.
  • Правильные эксперименты могут помочь организации двигаться вперед, но в любом случае успех зависит от поддержки со стороны вашего руководства. Найдите способы привлечь ваше руководство к своим идеям, чтобы они приняли более плоскую иерархию, которая следует из делегирования решений командам, и чтобы они помогли командам найти время для повышения своей компетенции и внесения улучшений.

Для организаций, которые занимаются разработкой программного обеспечения, гибкие методы теперь являются подходом по умолчанию, особенно для стартапов, и рынок наводнен отчетами об опыте и фреймворками, которые могут помочь облегчить гибкие методы работы для команд, которые «прирождены гибкими». Но куда вы обратитесь, если 1) вы не занимаетесь разработкой программного обеспечения и 2) вы – организация с долгой историей иерархического управления проектами? В 2017 году мы задали себе этот вопрос, когда наш ИТ-директор воскликнул: «Мы переходим к гибкости, и у вас есть полная свобода решать, как это сделать».

В нашем контексте было около 100 инженеров, которые отвечали за ИТ-инфраструктуру в LEGO Group, датской компании по производству игрушек, которая сегодня имеет фабрики и офисы по всему миру и насчитывает 18 000 человек. Наш отдел (Инфраструктура и безопасность, I&S) занимался всем, начиная от внутреннего хостинга, сети, интеграции приложений, платформы ERP, кибербезопасности, мобильных телефонов и персональных компьютеров, и сегодня мы расширили портфель, включив также публичные облачные хостинговые платформы.

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

Наш подход к гибкой трансформации был поэтапным – мы не пытались ее планировать. Наша путеводная звезда заключалась в том, чтобы постоянно пытаться делать шаги к лучшему и более гибкому способу работы, вводя эксперименты и извлекая уроки из них. Чтобы помочь нам структурировать подход к проведению экспериментов, мы использовали компас: Scrum @ Scale.1, созданный Джеффом Сазерлендом. Scrum @ Scale определяет 12 компонентов, каждый из которых обеспечивает конкретное представление об организации, и описывает желаемое поведение для гибкой организации, но не предписывает никаких решений. Одним из компонентов является процесс на уровне команды – если команды устойчиво обеспечивают клиентов. Другой компонент – это доставка – насколько наши пользователи довольны нашими доставками и процессом доставки.

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

В этой статье, второй из серии о том, как «долг» можно использовать для управления Agile-путешествием, мы приведем два примера запахов, связанных с техническим долгом, объясним симптомы, влияние на бизнес и нашу организацию. Опишите эксперименты (контрмеры), которые мы внедрили, чтобы попытаться удалить запах, и дайте некоторые конкретные – надеюсь, практические – советы, которые могут вдохновить вас, если вы почувствуете похожие запахи в своей организации.

Запах №1. Старый переключатель (эроо)

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

Срок службы многих устройств подошел к концу или приблизился к возрасту, когда выход на пенсию был единственным выходом. Другими словами, наша сетевая инфраструктура была явным случаем технической задолженности. В Scrum @ Scale мы определили проблему как препятствие для «командного процесса» сетевой команды, поскольку перед командой стояла задача повысить свою производительность и действовать таким образом, чтобы это было устойчивым и обогащающим команду. Как мы объясним ниже, команда не смогла решить проблемы самостоятельно – их пришлось передать на более высокий уровень (в «Исполнительную группу действий»).

Симптомы

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

Влияние

Если сетевая инфраструктура не является вашей специализацией, вы можете задаться вопросом, насколько требования к подключению действительно могут измениться за 10 лет? Действительно ли сетевой команде нужно разработать совершенно новое решение и воплотить в жизнь мечту DevOps? Ответ на этот вопрос – да! Сегодняшние (не говоря уже о завтрашних) требования к функциям безопасности и производительности значительно отличаются от требований 10-летней давности; сетевая инфраструктура играет ключевую роль в области кибербезопасности, защищая жизненно важные бизнес-процессы и приложения путем управления трафиком данных, и сеть должна поддерживать значительно увеличивающийся объем трафика данных, который, например, является результатом новых потоковых сервисов и IoT-сервисов. Сетевая группа не смогла оправдать эти ожидания с помощью устаревшей технологии, которую мы пытались использовать и поддерживать, и, таким образом, это оказало влияние на бизнес.

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

Контрмера

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

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

Обучение

Это сработало. И это сработало как раз вовремя, чтобы гарантировать, что, когда мир был закрыт из-за Covid-19 в первом квартале 2020 года, мы смогли установить новую настройку VPN за считанные дни и обеспечить, чтобы все 14000 белых воротничков могли работать из дома. без проблем, когда их отправили домой. Год спустя старая сетевая платформа для офисов и заводов работает и продолжает работать, поддерживая бизнес, в то время как новый сетевой дизайн для заводов и офисов был разработан и находится в процессе глобального развертывания. Оказывается, это развертывание сопряжено с новыми проблемами, над которыми мы планируем эксперименты, но это уже другая история.

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

Запах №2. Развертывания

Если вы работаете в индустрии программного обеспечения, вы, вероятно, знаете все о хлопотах, связанных с оркестровкой и автоматизацией выпусков (если вы не работаете в индустрии программного обеспечения, «выпуск» эквивалентен тому, когда вы доставляете что-то – новое – своим клиентам. ). Этот запах связан с нашим стремлением выпускать все быстрее и быстрее. В конце концов, большая часть проворных призывов к оружию связана с увеличением скорости (доставляемой ценности).

Раньше у нас был подход сверху вниз, чтобы контролировать, чтобы выпускаемые нами выпуски были достаточно высокого качества, чтобы их можно было представить в мире. У нас были еженедельные собрания совета по выпуску, проводимые линейными менеджерами, которые дважды проверяли и подписывали выпуск и несли общую ответственность за результат. Этот подход не работал бы по двум причинам: 1) для достижения успеха в увеличении скорости нам нужно было отказаться от подхода сверху-вниз: полномочия по принятию решений должны были быть переданы командам, и 2) у нас не было линейных менеджеров. больше, так кто на самом деле несет ответственность? Это был самый очевидный пример возможности, когда мы могли позволить командам решать, «как».

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

Поскольку команды были заняты созданием ценности для бизнеса, никогда не было приоритетом тратить время на косвенные действия по добавлению стоимости, такие как поиск новых способов обеспечения качества изменений. Это пример процесса долга, и в Scrum @ Scale мы помещаем его в раздел «Доставка» (в цикле Scrum Master), поскольку он связан с доставкой клиентам постоянного потока ценных готовых продуктов – с высоким качеством.

Симптомы

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

Влияние

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

Контрмера

Мы глубоко вздохнули и попытались вспомнить, чего мы хотели достичь: мы хотели, чтобы у команд была свобода решать, как, потому что мы хотели скорость и маневренность. И мы знали, что не сможем добиться этого, навязывая улучшения. Поэтому вместо этого мы создали структуру для действий команд – четкую схему игрового поля и правил. Мы назвали эту структуру «Модель зрелости выпуска» (RMM).3, и это показано на рисунке 2.

RMM выделил семь областей, имеющих отношение к процессу выпуска (игровое поле), включая то, как хранится исходный код, как проводятся тесты и проверки, как оценивается риск, как запросы на изменение документируются и утверждаются, как организуется развертывание и как команда учится на опыте, который они получают от своих релизов. Правила заключались в том, что командам было предложено: 1) оценить свою текущую зрелость (по 4-уровневой шкале от «это не то, что мы делаем» до «это полностью автоматизировано в наших настройках»), 2) принять решение по двум направлениям. где они возьмут на себя обязательство улучшить свою зрелость в следующем квартале, исходя из их оценки того, где это будет наиболее полезно в их конкретной ситуации, и 3) решить, как они будут совершенствоваться. Со временем идея заключалась в том, чтобы сделать оценки и планы действий команд прозрачными для всех, чтобы облегчить обмен знаниями и вдохновение в отделе.

Рисунок 2. Модель зрелости релиза, первый набросок

Обучение

Это не сработало. Подход с игровым полем и правилами был очень хорошо принят в командах, на которых мы его тестировали – они с нетерпением обсуждали, где и как улучшить. Но инициатива быстро провалилась, поскольку команды не уходили от обсуждения. Несмотря на то, что мы создали им вакуум для принятия решений И предоставили структуру для их поддержки, чего-то не хватало. Мы пришли к выводу, что остались две нерешенные проблемы: 1) Нам не удалось сделать это приоритетом в командах – стимулом к ​​работе над созданием ценности для клиентов было преобладание соображений по улучшениям. Возможно, мы могли бы смягчить эффект отсутствия стимула, если бы у нас было 2) убедиться, что у инженеров было время сосредоточиться на том, чтобы стать хорошими в выпуске и знать, где черпать вдохновение, инструменты и компетенции, но мы этого не сделали.

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

Заключительные замечания

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

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

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

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

Об авторах

Энн Абелл является стратегическим советником в LEGO Group. Консультирует технического директора по продуктовой и организационной стратегии, работал мастером схватки и владельцем продукта. Абелл имеет степень доктора философии в области управления портфелем проектов информационных технологий, степень магистра информационных технологий и степень бакалавра политических наук; является сертифицированным специалистом по Scrum @ Scale и сертифицирован в ITIL Foundation и ITIL Service Operation.

Карстен Русенг Якобсен является тренером по Agile в Grow Beyond. Якобсен имеет более чем 25-летний практический опыт работы с управлением изменениями в крупных датских компаниях; является одним из пионеров гибкой разработки и с 2005 года работает над внедрением гибкого мышления и культуры для достижения гибкости бизнеса. Якобсен представил свой опыт на международных конференциях, таких как SEPG 2007, Agile 2007, Agile 2008, Agile 2009, Agile 2011, OOP 2014 и XP 2020. Якобсен имеет диплом инженера бизнес-администрирования (EBA), Scrum-тренер от Scrum Inc., сертифицированный Scrum @Scale Trainer (CSaST), сертифицированный специалист по Scrum @ Scale, сертифицированный Scrum Professional (CSP). Сертифицированный мастер Scrum (CSM) и сертифицированный владелец продукта Scrum (CSPO).

Расмус Лунд Дженсен является тренером по Agile в LEGO Group. Дженсен обучает, тренирует и развивает лидеров в их роли мастеров схватки и владельцев продуктов, чтобы способствовать гибкой трансформации. Дженсен имеет степень магистра инженерных наук, развития бизнеса на основе технологий и степень бакалавра наук в области инженера-электрика. Дженсен является сертифицированным мастером Scrum, сертифицированным тренером команды Scrum Alliance и практиком Scrum @ Scale. Посещал Leading Organization and Change (MIT), Summer Institute for General Management, Stanford University GSB, Ситуационное лидерство II (CfL).

Ресурсы

1 Для получения дополнительной информации о Scrum @ Scale (Scrum Inc.) вы можете посетить это.

2 Вы можете добавить, что более «правильный гибкий» подход – это непрерывный выпуск. Это также ориентир, над которым мы работаем. Однако мы пришли к выводу, что мы недостаточно зрелая организация, чтобы это произошло. Еще.

3 Модель является «самодельной», поскольку мы не смогли найти структуру, которая обеспечивала бы достаточную структуру И свободу для достижения цели, но мы не предлагаем проводить исчерпывающий поиск.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button