Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

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

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

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

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

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

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

Теперь вспомним пример с паромом из Эдмондса в Кингстон. Какое расширение возможно здесь? В данный момент штат Вашингтон рассматривает два варианта. Один из них – заменить нынешний устаревающий флот паромов новыми, более крупными и эффективными судами. Кроме того, в Вашингтоне часто применяются понтонные мосты. Два из них – через озеро Вашингтон, в том числе и тот, который составляет часть SR-520 (возможно, это самый длинный такой мост в мире), а еще один ведет через канал Худ и является частью шоссе SR-104. Сейчас рассматривается возможность постройки нового, рекордного по длине моста через залив Пьюджет, продолжающего SR-104 и полностью заменяющего паромную переправу. Планируемый мост не только решит проблему ограниченной мощности в пиковое время, но и устранит проблемы ограниченной доступности, которые мешают рассматривать все паромные переправы как вариант организации движения. Этот мост будет способствовать экономическому росту полуостровов Китсап и Олимпик. Возможно, лет через пятьдесят в другой книге будет обсуждаться понтонный мост на трассе SR-104 через залив Пьюджет, который тоже назовут бутылочным горлышком и ресурсом ограниченной мощности во время пикового движения.

• Бутылочные горлышки сдерживают и ограничивают поток работы.

• Бутылочные горлышки бывают двух типов: с ограничением мощности – неспособностью выполнять больше работы, и с ограничением доступности – ограниченной мощностью из-за ограниченной (но обычно предсказуемой) доступности.

• Мы управляем бутылочными горлышками в соответствии с пятью направляющими шагами теории ограничений.

• Повышение мощности бутылочного горлышка называется расширением.

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

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

• Действия по увеличению мощности обычно затратны с точки зрения денег и времени и нередко требуют стратегических вложений в оптимизацию процесса.

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

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

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