Читать онлайн «Канбан. Альтернативный путь в Agile». Страница 54

Смешение классов обслуживания

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

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

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

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

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

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

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

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

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

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

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

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

В 2007 году в Corbis это достигалось постепенно. Сначала внедрили канбан-систему – визуальную доску и электронное средство отслеживания. Вместе с этим пришла прозрачность. Бизнес оказался сильнее вовлечен в процесс разработки ПО и в наблюдение за производительностью этого подразделения. Создавались отчеты, демонстрирующие количество нерешенных проблем и заблокированных единиц работы, а также среднее время разрешения этих задач. (Рис. 12.6. Отчет о проблемах и заблокированных единицах работы)

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

Рис. 19.1. Доска с мусорной корзиной

Рис. 19.2. Отчет о непринятой и отмененной работе, демонстрирующий незавершенные рабочие единицы за прошлый месяц

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