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

Использование небольших команд для масштабирования гибкости

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

  • Создание команд помогает увеличить гибкость в крупных организациях за счет увеличения возможностей для укрепления доверия, неудач и более быстрого обучения.
  • Культурные изменения в организациях требуют времени и «поддержки» всех заинтересованных сторон.
  • Организации, применяющие гибкую методологию, должны иметь желание отказаться от мышления «командование и контроль».
  • Недостаточно реорганизовать отдельные команды, работающие над частями проекта, для гибкой разработки; Успех требует, чтобы вся организация по разработке продукта была правильно структурирована
  • Во время реализации Scrum важно иметь четкие определения ролей; правильно определенные роли и цели позволяют членам команды выступать в качестве межгрупповых участников и обеспечивает лучшую координацию в рамках более крупной организации

В этой статье вы познакомитесь с внедрением Agile-методологии в Red Hat в организации, занимающейся разработкой платформ. Команды, работающие над флагманским продуктом Red Hat, Red Hat Enterprise Linux (RHEL), операционной системой Linux, делятся на функциональные группы, называемые подсистемами. Здесь мы собираемся сосредоточиться на Agile-путешествии одной из конкретных команд, подсистеме управления идентификацией, представленной с точки зрения практикующего Agile, работающего с командой. Внедрение Agile, описанное в этой статье, не было единообразным для всей инженерной организации. Это сделано намеренно, поскольку позволяет каждой команде иметь время и пространство для разработки подходящего для них способа выполнения работы. Это также означает, что разные команды имеют разный уровень зрелости и внедрения Agile.

В Red Hat единая команда Agile Practice руководствуется идеей, что мы будем делать то, что правильно, и когда это правильно. Эта команда, состоящая из практиков Agile, обеспечивает обучение, руководство и выступает в качестве коучей Agile для отдельных команд, помогая им постоянно совершенствоваться и выбирать наиболее подходящую методологию. Некоторые команды Red Hat используют Scrum, некоторые используют Kanban, а некоторые используют гибридный подход.

Таким образом, Agile-внедрение имеет разный уровень зрелости для разных продуктовых команд. Для RHEL в целом этот путь начался более шести лет назад. Однако подсистема Identity Management начала свой путь к Agile четыре года назад и, следовательно, находится на другом уровне зрелости по сравнению с другими командами подсистем. Red Hat выбрала нерелигиозный Agile-подход, поскольку мы считаем, что это лучший способ приблизиться к нашим коллегам и постепенно вводить изменения. Поскольку Agile – это непрерывный процесс, у команды нет реальной конечной точки, чтобы стать Agile, особенно у Scrum-команд, работающих в непрерывных циклах ретроспективы и улучшений.

Ситуация в Red Hat – контекст для перемен

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

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

В основной группе было более 40 участников, разделенных между командами управления качеством и инжиниринга, а также полностью разобщенная группа документации. Менеджеры Functional People пытались внедрить методологию Scrum, не отказываясь от традиционного подхода «командование и контроль». Это привело к ситуации, когда у трех нестабильных Scrum-команд было 10+ Scrum-досок, что показало противоречивые приоритеты. Кроме того, состав команды Scrum менялся на каждой итерации, когда люди переходили между этими командами.

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

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

Создание небольших команд разработчиков программного обеспечения

Небольшие группы разработчиков программного обеспечения могут увеличить объем выполненной работы благодаря этим трем небольшим группам разработчиков программного обеспечения:

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

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

Также обратите внимание, что это изменение не произошло в одночасье. Вначале я начал с посещения различных собраний команды, чтобы увидеть, в какой динамике они работают. И да, у этих 40-летних людей было много встреч. В основном мое внимание было направлено на то, кто есть кто и кто ведет большую часть разговоров. Я начал с поиска простых шаблонов, например встречи проходят вовремя? У всех есть шанс внести свой вклад? Есть ли кто-нибудь, кто доминирует в разговоре? Отправной точкой было узнать всех членов команды как людей и понять, как они работают в команде.

Следующим шагом было представить план улучшения команде подсистемы. Этот план включал реорганизацию функциональных команд, разделенных менеджерами по персоналу, и существующую структуру команды Scrum. Здесь важно помнить, что эта группа думала, что у них есть три Scrum-команды, но, поскольку все меняли команды после каждой итерации, у них фактически была одна Scrum-команда. Кроме того, у них было более 10 различных досок Scrum, что добавляло путаницы. Наконец, не было четкого определения «готово», из-за чего сделать это было очень сложно.

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

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

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

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

В ходе работы Scrum-команд одним из интересных ретроспективных открытий стало то, что люди тратили много времени на решение проблем инфраструктуры, конвейера, автоматизации тестирования и других подобных проблем. Нашим выводом было создание команды DevOps Scrum в группе подсистемы управления идентификацией, чтобы сосредоточиться на CI / автоматическом тестировании и автоматизации различных ручных процессов. Мы хотели передать эту работу людям, которые могли бы сосредоточиться на ней и одновременно создать пространство для более глубокого внимания для других участников, которые теперь могли бы полагаться на эту инфраструктуру, а не думать о ней. Кроме того, эта работа требовала тесного сотрудничества с различными другими командами и представителями специалистов-практиков DevOps более широкой организации. Эта команда DevOps Scrum обеспечила руководство и технический вклад, который в конечном итоге помог создать решение CI, интегрированное в более крупную экосистему Red Hat Enterprise Linux и системы CI, создаваемые другими командами. Что еще более важно, эта работа также способствовала изменению мышления инженеров, чтобы сосредоточиться на автоматизации и автоматизации тестирования.

Измерение успеха

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

Мы обнаружили, что члены команд из всех трех Scrum-команд сообщили об увеличении чувства:

  • Общая ответственность за выполненные работы
  • Взаимное доверие
  • Обмен и сотрудничество

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

Обучение

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

Agile не всегда означает гибкость. Исходное состояние этой группы продемонстрировало это по тому, как они работали. Они прошли обучение и в итоге получили ротацию персонажей в scrum-командах с 10+ досками. После того, как я приехал, мы провели еще один цикл обучения Agile. Это произошло после того, как команда решила заняться Agile и помогла каждому приобрести инструменты для достижения успеха. Несмотря на свои предыдущие задачи, они, как и многие новые команды Agile, были в восторге. Знание – сила. Но даже помощь в переходе членов команды от новичков к любителям заставляла их бороться с такими понятиями, как способности. Они, как и многие другие команды, изо всех сил пытались понять, каков уровень потенциала их команды. Они были склонны чрезмерно загружать объем работы, выполняемой в каждом спринте. Именно здесь Скрам-мастер может поддержать, помогая вести команду к зрелости, когда они учатся приносить пользу и нести за это ответственность как команда.

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

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

Предложения для организаций, которые хотят работать с небольшими командами

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

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

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

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

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

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

Доминика Була является практикующим Agile в Red Hat, Чешская Республика. Она одновременно является сертифицированным Scrum Master и сертифицированным специалистом по Agile-методике PMI. Будучи активным участником сообщества практиков Agile и DevOps, Була вносит свой вклад в Opensource.com. За время своего пути с Agile она тренировала несколько инженерных команд. Була имеет степень магистра, и ее образование было сосредоточено на культурных исследованиях и психологии. Она применила это к различным вспомогательным и не связанным с инженерными технологиями ролям, а также работала в сфере бизнеса, финансов, управления процессами и предоставления услуг. Следуйте за ней в Twitter @domibula.

Она говорила о том, что на Scrum Master Summit 2021 можно больше работать с небольшими командами.

Related Articles

Leave a Reply

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

Back to top button