Канбан. Альтернативный путь в Agile - [77]

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

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

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

Например, в Corbis Дуг Буррос был назначен билд-инженером на проект технической поддержки. Но одновременно выполнял и две другие задачи: создавал новые среды и сопровождал существующие. Как инженер по управлению конфигурациями, он должен был поддерживать актуальность сред, то есть следить за обновлением оперативной системы, применением патчей и обновлений для серверов баз данных и межплатформенного программного обеспечения, системных конфигураций, топологии сети и т. д. Примерно час в день у него занимало выполнение функций билд-инженера – обычно с десяти до одиннадцати утра. Если разработчики в три часа дня обнаруживали, что им необходима тестовая сборка, приходилось ждать до начала следующего рабочего дня. Билд-инженер был ресурсом с ограниченной доступностью. Работа блокировалась, и, поскольку техническое обслуживание выполнялось при помощи канбан-системы, задания быстро выстраивались в очередь по всей цепочке создания ценности, вызывая простой других сотрудников.

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

Загрузка и защита

Прежде всего следовало понять, что Дуг – это ресурс с ограниченной доступностью, и выявить влияние, которое оказывает этот фактор. Задания выстраивались в очередь за время недоступности билд-инженера, потому что канбан-лимиты были жестко определены. Он стал источником вариативности в потоке, значит, следовало организовать буфер заданий перед Дугом. При этом требовался достаточно большой буфер, чтобы поток продолжал двигаться, но не настолько, чтобы Дуг превратился в ресурс с ограничением мощности. Я поговорил с ним, и оказалось, что он легко может собирать до семи элементов за час своей работы в этой должности. Поэтому мы создали буфер с канбан-лимитом, равным семи, дали знать об этом всем участникам цепочки создания ценности и начертили на стене карточек новый столбец под названием «Сборка готова». Общий WIP-лимит системы увеличился примерно на 20 %, но это принесло результат. Хотя сборки были ресурсом с ограниченной доступностью, действия выше по цепочке могли обеспечивать равномерный поток работы в течение дня. В результате существенно повысилась пропускная способность, а время выполнения сократилось, несмотря на увеличение WIP-лимита. Мы также решили изменить график Дуга: вместо одного часа подряд два раза по полчаса. Их можно было разнести по времени: тридцать минут утром и столько же – днем. Это облегчило бы поток и снизило давление на буфер для ожидания доступа. Возможно, от этого размер буфера уменьшился бы до двух или трех, что повысило бы WIP-лимит всего на 10 % и привело к сокращению времени выполнения для всей системы.

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

Подчинение ограничению

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

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