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

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

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

Операционные системы, базы данных, платформы, языки, API и сервисные архитектуры со временем меняются. Для работы с этими изменениями нужно обновлять и код.

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

Еще одна стратегия по увеличению предсказуемости – назначение общей WIP-мощности для отдельных типов. Например, в моей команде обслуживания в Corbis были разрешены только две единицы IT-обслуживания одновременно. Это ограничивало мощность, потраченную на API и обновления базы данных. Такая стратегия особенно полезна, когда типы разделяются по размеру или требуемым усилиям – как, например, эпик, история или песчинка. Назначив конкретную мощность для каждого типа, вы сможете поддержать чуткость системы и увеличить предсказуемость.

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

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

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

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

Ускоренные запросы – это внешние вариации, поэтому они будут описаны в следующем разделе.

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

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

Рассмотрим пример команды с WIP-лимитом в 20 единиц, из которых 4 приходятся на единицы с фиксированной датой поставки, 10 – на элементы стандартного класса и 6 – на единицы нематериального класса. Можно либо установить правило, что этих более мелких лимитов нужно строго придерживаться, либо ослабить жесткость, чтобы стандартный или нематериальный элемент мог занимать место элемента с фиксированной датой поставки, когда сезонный спрос на такие элементы недостаточен. В разное время года эти правила могут меняться ради общего экономического выигрыша и обеспечения большей предсказуемости системы.

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

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