Альтернативный подход к борьбе с вариативностью трудозатрат

 

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

 

Введение классов обслуживания

 

Два наиболее очевидных метода визуальной дифференциации карточек на стене – это использование разных цветов и «плавательных дорожек». Однако в крупных проектах у каждой карточки есть три атрибута, о которых необходимо сообщить: это тип единицы работы, уровень иерархии и класс обслуживания. Стоит заметить, что в нашем примере (рис. 13.2) было принято решение завести разные типы единиц работы для различных иерархических уровней, а также применить и цвета, и «плавательные дорожки» для обозначения самих уровней. То есть для иерархии фактически использовались два метода визуализации, а это обычно приводит к перегрузке.

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

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

 

Системная интеграция

 

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

 

Управление общими ресурсами

 

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

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

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

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

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

 

Выводы

 

• Крупные проекты должны выполняться в соответствии с ключевыми принципами Канбана.

• WIP‑лимиты, каденция приоритетов, каденция релизов и классы обслуживания остаются полезными и в крупных проектах.

• Крупные проекты обычно имеют иерархические требования, эти уровни иерархии следует моделировать при помощи типов единиц работы.

• Обычно команды отслеживают два верхних уровня иерархии требований на стене карточек и задают WIP‑лимиты на одном или обоих уровнях.

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

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

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

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

• Популярный метод демонстрации иерархии и облегчения задания WIP‑лимитов – так называемые плавательные дорожки.

• Крупные WIP ограничиваются количеством «плавательных дорожек».

• Детализированные WIP при желании можно ограничить на каждой «плавательной дорожке».

• Как правило, на каждую «плавательную дорожку» назначаются небольшие межфункциональные команды.

• Спрос на общие ресурсы можно визуализировать при помощи небольших стикеров, прикрепляемых к обычным рабочим элементам.

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

• Общие ресурсы должны разработать собственные канбан‑системы.

• Сеть канбан‑систем для общих ресурсов в портфеле проектов можно считать архитектурой для обслуживания запросов на разработку ПО.

 

 

Глава 14

Операционный обзор

 

До совещания

 

Половина восьмого утра, вторая пятница марта 2007 года. Я пришел на работу так рано, потому что сегодня у нас в отделе четвертый ежемесячный анализ производственного процесса. Со мной Рик Гарбер, менеджер нашей группы процессов разработки ПО. Рик будет координатором совещания – он отвечает за повестку. Сейчас он распечатывает раздаточный материал для сегодняшнего анализа, который состоит примерно из 70 слайдов презентации в PowerPoint. Когда он заканчивает, мы направляемся в Harbor Club в деловой части Сиэтла с коробкой раздаточного материала на сто человек. Совещание назначено на 8:30 утра, но завтрак подается с восьми. Приглашены все сотрудники моей организации и компании моего коллеги Эрика Арнольда. Однако поскольку некоторые из них работают в Индии, другие – в других штатах США, а кое‑кто не может посетить совещание по личным причинам, присутствует обычно человек восемьдесят.

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

Группа начинает собираться, все стараются успеть к завтраку. Зал находится на верхнем этаже сиэтлского небоскреба, откуда открывается прекрасный вид на город, гавань, пирсы и Эллиотт‑Бэй[8]. В зале стоят круглые столы, за каждым – от шести до восьми человек. В одном конце зала – прожектор и кафедра. Рик действует в строгом соответствии с расписанием. Каждому выступающему дается примерно восемь минут, чтобы показать свои четыре‑пять слайдов. Предусмотрены несколько отрезков времени на случай непредвиденных задержек, вызванных вопросами и обсуждениями. Я начинаю совещание с коротких вступительных замечаний: прошу всех мысленно вернуться к концу января и вспомнить, чем мы тогда занимались. Я напоминаю всем, что мы должны сейчас проанализировать работу организации за февраль. Рик подобрал отличную картинку из архивов компании, которая символизирует основную тему месяца и помогает вспомнить о том, чем мы тогда занимались.

 

Сразу задайте деловой тон

 

Я передаю слово Рику, который рассказывает о действиях за последний месяц и их текущем статусе. Затем слово берет наш финансовый аналитик, она представляет резюме производительности компании за месяц. Вот причина, по которой мы откладываем наши встречи до второй пятницы следующего месяца, – этого времени достаточно, чтобы подвести финансовые итоги месяца. Аналитик разъясняет детали бюджета для двух центров затрат – моего и Эрика. Мы рассматриваем соотношение запланированного бюджета и реального, а также планы работы сотрудников. Обсуждаются открытые заявки, а членам команды предлагается выдвигать кандидатов на имеющиеся вакансии. Благодаря первому этапу встречи все ее участники получают представление о том, насколько хорошо идут дела у команды разработки и каким образом она укладывается в бюджет. Это помогает понять, есть ли у нас резервы для покупки мониторов с плоским экраном, новых компьютеров и т. д. Мы начинаем с финансовых показателей, чтобы напомнить всем членам команды, что компания наняла их заниматься бизнесом, а не развлекаться, набирая на клавиатуре единицы и нолики ради собственного удовольствия.