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

Подъезжая к переправе, вы платите определенную сумму, после чего вас просят подождать. Обычное время ожидания в очереди – около 30 минут: парому требуется около получаса, чтобы пересечь залив Пьюджет, затем 10–15 минут уходит на разгрузку транспортных средств и примерно столько же – на погрузку новых перед отплытием. Как правило, паромная компания использует два судна, поэтому отправление происходит примерно каждые 50 минут. В часы пик на маршруте иногда появляется третий паром, что сокращает время ожидания примерно до 35 минут.

Б о льшую часть времени паромы ходят с почти полной загрузкой, но система ограничена не мощностью. Скопление машин в зоне ожидания – в буфере – и затем загрузка на паром для отплытия (пакетная передача) не говорят о том, что мощность ресурса ограничена. Это свидетельствует об ограниченной доступности. Паромы отходят всего раз или два в час и способны вместить около 220 машин.

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

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

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

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

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

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