Шухарт, Деминг и Джуран опубликовали множество работ по исследованию вариативности и ее использованию в качестве техники управления, а также как основания для программы усовершенствований. Кроме того, существует немало публикаций, рассказывающих о методе количественной оценки, известном как статистический контроль процессов (СКП) и ставшем основным средством изучения вариативности и борьбы с нею. Теперь СКП взят на вооружение и командами, использующими Канбан. Однако СКП и его применение считается более серьезной темой, к которой мы обратимся в одной из следующих книг. Здесь же только затронем проблему вариативности.

Шухарт разделял вариативность и вариации в производственных показателях на два типа – внутреннюю и внешнюю.

Внутренние источники вариативности – это вариации, которые находятся под контролем задействованной системы. В рамках Канбан-подхода к IT и разработке ПО мы определяем систему как процесс, который задается набором правил, управляющих ее эксплуатацией. Эти правила могут подвергнуться влиянию изменений, вносимых сотрудниками, командой или руководством. Изменения в правилах трансформируют и эксплуатацию системы, и ее производительность. Тем самым изменения в определении процесса – это изменения, которые затрагивают внутренние источники вариативности. Забавно, что такие внутренние вариации Шухарт назвал случайными. Слово «случайный» предполагает, что вариации имеют непредсказуемый характер, что является прямым следствием структуры системы. Но не предполагается, что непредсказуемость равномерно распределена или укладывается в рамки нормального распределения. Изменения в структуре процесса, вызванные изменениями внутренних правил, повлияют на медианное распределение, его распространение и форму.

Приведем пример. Отбивающий в бейсболе обладает коэффициентом ударов (известным также как средний уровень), который показывает, как часто он наносил удары, приводившие как минимум к взятию первой базы. У разных отбивающих разные коэффициенты, обычно они колеблются от 0,1 до 0,35. В любой день такой игрок может продемонстрировать показатели ниже своего среднего коэффициента ударов. Это зависит от ряда факторов: выбора питчера[13], коэффициента успешности ударов других игроков, а также от специфики подач.

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

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

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

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

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

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

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

Как , я хочу , чтобы .

Использование шаблона привело к стандартизации написания пользовательских историй. Один из авторов такого подхода, Тим Маккиннон, в 2008 году сообщил мне, что, по его данным, в среднем на создание пользовательской истории требуется 1,2 дня, а вариативность составляет от половины суток до примерно четырех дней.

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

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