Третья Канбан-метрика - 3. Control Chart

нужна метрика, которая позволяет это делать

В первой статье мы обсудили Scatterplot — график, который помогает менеджерам выявить общие тенденции и скрытые проблемы в рабочих процессах. Во второй статье мы рассмотрели Run Chart, инструмент для обнаружения трендов и сдвигов в данных. Теперь настало время поговорить о Control Chart.

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

Если переводить “Control Chart” буквально, то это название будет звучать как “Контрольной диаграмма”. И как следует из названия, эта диаграмма должна помогать что-то контролировать. Но что именно? И каким образом? Давайте разберемся.

Еще несколько лет назад на тренингах по Канбан-методу (KSD), можно было увидеть, как тренер, ведущий занятие, во время объяснения Канбан-метрик, рисовал точечный график Lead Time, пририсовывал к нему горизонтальные линии контрольных пределов, и подписывал заголовок “Контрольная диаграмма”. Затем, тренер обычно объяснял, что значения выходящие за контрольные пределы, это аномалии, с которыми надо бороться. И указывал на графике ширину контрольного диапазона равную 6σ (шесть сигма).

Однако, когда обучающиеся задавали вопросы “А как эти самые сигма надо вычислять? И от какой линии их надо откладывать, чтобы получить контрольные пределы?”, то, зачастую, начинался разнобой в ответах. Некоторые тренера говорили, что нужно нарисовать линию среднего арифметического и в качестве контрольных пределов отсчитать от нее среднеквадратичное отклонение. Другие тренера говорили, что нужно взять скользящее среднее, и вычислить дисперсию. А кто-то ссылался на таблицы коэффициентов из книги Уилбера и Чамберса и предлагал в качестве центральной линии брать целевое значение Lead Tiime.

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

И эта неразбериха длится до сих пор. Например, на сайте онлайн-трекера задач Kaiten под названием “Контрольная диаграмма” можно увидеть точечную диаграмму Lead Time, с некой горизонтальной линией, которая представляет собой значение Lead Time, к которому заказчик и исполнитель договорились стремиться (Service Level Agreement).

А в широко распространенном трекере задач JIRA есть своя версия Control Chart, на которой можно увидеть точечную диаграмму Lead Time с линией абсолютного среднего значения, линией скользящего среднего и голубой зоной стандартного отклонения.

Глядя на это разнообразие диаграмм под названием "Control Chart", я решил разобраться, а как же все-таки должна выглядеть эта самая контрольная диаграмма, и как ее применять?

К сожалению, Kanban University в этом вопросе нам не сильно помогает разобраться. Вот что написано в официальном Kanban Glossary от Kanban University:

Примерные перевод этого определения такой: “Control Chart это, обычно, Run Chart показывающий контрольные диапазоны, за пределами которых процесс можно считать «вышедшим из-под контроля» в каком-то конкретном смысле”

Это определение не объясняет многих моментов: как именно эти контрольные диапазоны надо рассчитывать и отображать? Как с ними работать? Почему выход за эти пределы означает неконтролируемый процесс?

Если попробовать обратиться к классическим книгам по Канбан-методу, то, как ни странно, в них мы тоже не найдем пояснения о Control Chart. Ни Дэвид Андерсон, ни Даниэль Ваканти, ни Майк Барроуз в своих книгах эту диаграмму не упоминают.

А русский перевод книги Майкла Барроуза “Kanban from the Inside” (по русски называется “Канбан-метод. Улучшение системы управления”) лишь все запутывает, потому что график который в оригинальной книге Барроуза в главе 19 “Analyze Demand and Capability” подписан как “run chart” (хотя это явно scatterplot):

Но вот в русском переводе этой книги в той же главе название этого графика переведено как “контрольная диаграмма”. Неожиданно и непонятно.

Такой перевод на русский язык еще больше всех запутал.

Тем не менее, термин “Контрольная диаграмма” очень распространен в среде русскоязычных Канбан-тренеров, и регулярно звучит при обучении Канбан-методу. Пора внести ясность в этом вопросе, и расставить все "точки над Ё"

Чтобы разобраться в том, что же такое “Контрольная диаграмма”, придется начать издалека и вспомнить имя Уолтера Шухарта - основоположника статистического управления качеством. Этот американский статистик, работал в начале XX-века в компании Bell Telephone Laboratories, и оставил нам такой задел знаний, подходов и методов, что на основе его работ позже появился цикл PDCA, подход 6-сигма (Six Sigma), бережливое производство (Lean Manufacturing), Производственная система Тойота (TPS), Канбан-метод и даже Scrum.

В Bell Telephone Laboratories Уолтер Шухарт решал вполне прикладные задачи, связанные с обеспечением качества. И для решения этих задач разработал новый подход на основе статистики. Частью этого подхода были так называмые “контрольными карты”.

С конца XIX, до середины XX века компания Bell занималась прокладкой телефонных линий через американский континент. Благодаря усилиям этой компании, вся территория США к середине века была опутана проводами телефонных линий, которые обеспечили быстрый охват населения США новым средством связи - телефоном

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

Протяженность первой телефонной линии, построенной в 1915 года, от западного к восточном побережью равнялась 3400 миль (5471 км). А к 1920-му году общая протяженность телефонных линий приближалась к 20 миллионам миль (34 миллиона километров). Можете сами посчитать сколько требовалось усилителей, чтобы обеспечить все эти линии стабильным сигналом (ответ: около 68 миллионов подстанций).

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

А на чем строилась первая электроника? Правильно - на электронных лампах! Точнее на вакуумных триодах, вот таких:

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

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

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

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

Молодому Уолтеру Шухарту предстояло придумать, как эту проблему решить. С самого начала он был фанатиком применения статистических методов. Его коллега и ученик Эдвард Деминг так писал об этом:

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

В попытке уменьшить затраты на проверки качества, коллегами Уолтера Шухарта по Bell Labs были разработаны методы выборочной проверки готовой продукции. Но большого эффекта для конечного потребителя это не давало. Лампы так же непредсказуемо перегорали во время эксплуатации.

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

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

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

Шухарт называл такие рабочие процессы статистически управляемыми:

Причины вариативности статистически управляемого рабочего процесса обусловлены только его внутренними особенностями и устройством. Причины, которые вызывают естественную вариативность системы Шухарт называл общими (common) причинами.

Примеры причин естественной вариативности на конвейере:

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

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

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

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

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

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

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

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

Такие причины Шухарт называл специальными (assignable) причинами.

Вариативность от специальных причин проявляется нерегулярно. Степень влияния этой вариативности на конечный результат сильно зависит от характера причины, которая ее вызывает.

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

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

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

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

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

Давайте рассмотрим на примере

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

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

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

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

Таким образом Контрольная карта Шухарта (ККШ), это сочетание двух графиков:

На Рис 3 видно, что среднее (X) и размахи(R) в каждой подгруппе находятся в “коридоре” контрольных пределов, не выходя за них. Это признак статистически управляемого рабочего процесса, течение которого подвержено лишь внутренним обычным (common) причинам.

А на Рис 4 видно, что и верхний график среднего (X), и нижний график размахов (R) регулярно выходит за контрольные пределы, что говорит о том, что рабочий процесс находится в статистически неуправляемом состоянии, и надо разбираться, какие внешние или внутренние специальные причины влияют не него. А после того, как выяснили эту специальную причину - ее надо устранить, чтобы рабочий процесс опять вернулся к статистически управляемому состоянию, на основе которого можно прогнозировать его поведение и в будущем.

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

Поэтому, когда вы слышите “Контрольная диаграмма (карта)” (Control Chart) вам следует уточнить - какая именно контрольная диаграмма (карта) имеется в виду?

Шухарт разработал 8 видов контрольных карт: 3 для непрерывных значений, и 5 для дискретных (в основном для работы с дефектами).

Тот пример контрольной карты который мы с вами рассматривали выше, называется X-bar и R-карта, по названию двух составляющих ее графиков: графика среднего значения (X-bar) и графика размахов (R-карта). И она применяется для однотипных деталей, которые можно объединить в однородные подгруппы и измерять. Очевидно, что для процессов разработки программного обеспечения эта контрольная карта не применима, так как каждая задача при разработке ПО - уникальна, и делать ее могут разные люди, так что объединять такие задачи в “однородные подгруппы” можно лишь с большой долей условности, а порой и совсем невозможно. Разве что, если это будут задачи на повторяющиеся вычисления по известной формуле, например, по таблице умножения. Но можно ли считать такую работу “интеллектуальной” - большой вопрос.

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

Кажется, что только XmR - карта хоть как-то может подойти для отображения Lead Time для задач интеллектуального труда. Верхняя часть XmR-диаграммы - X-карта, очень похожа на Run Chart, который мы разбирали в предыдущей статье. А нижняя часть - mR-диаграмма - дает дополнительную информацию о том, как сильно меняется во времени диапазон значений Lead Time.

Известная диаграмма JIRA Control Chart из трекера задач JIRA, по сути представляет собой упрощенный вариант XmR-карты.

На JIRA Control Chart в качестве меры средней тенденции можно видеть скользящее среднее Lead Time по последним 6 задачам (синяя линия), голубым фоном отмечены контрольные пределы вычисленные на основе стандартного отклонения от скользящего среднего.

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

Вот пример. Мы отфильтровали задачи на JIRA Control Chart по принципу равенства относительного размера - выбрали все задачи с оценкой Small. В левой части графика видно, что многие задачи с оценкой Small совсем не выглядят как маленькие, так как их Lead Time довольно большой. Но где-то с середины графика видна стабилизация - это следствие того, что мы начали планомерную работу по выявлению и устранению причин аномалий, и навели порядок с критериями того, как именно определять относительный размера задач, и какие задачи мы можем считать Small-задачами. В результате, мы видим, как голубая область стандартного отклонения сузилась, а синяя линия плавающего среднего сместилась в область меньших значений, что свидетельствует о том, что рабочий процесс стал более статистически прогнозируемым

JIRA Control Chart только для Small-задач

На этом примере видно, что “в лоб” контрольные карты Шухарта (ККШ) в IT, да и вообще в области интеллектуального труда на применимы. Нужно думать как именно адаптировать этот инструмент под особенности интеллектуального труда

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

Таблицу коэффициентов для каждого вида контрольных диаграмм можно посмотреть в книге Уилера и Чамберса “Статистическое управление процессами” или в ГОСТ Р ИСО 7870-2-2015

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

Но если говорить кратко, то для вычисления контрольных пределов ККШ нужно несколько вещей:

Интересующихся конкретными деталями отсылаю к книге Уилера и Чамберса “Статистическое управление процессами”, книге Юрия Адлера и Владимира Шпера “Практическое руководство по статистическому управлению процессами” и к ГОСТ Р ИСО 7870-2-2015

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

Но что делать, если мы говорим не о физическом производстве, а об интеллектуальных процессах, таких как разработка ПО? Хотя задачи здесь уникальны, цель остается прежней — стабилизировать процесс и сделать его предсказуемым. Давайте посмотрим, как этот подход может быть адаптирован для сферы разработки программного обеспечения

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

Аргументы против применения ККШ в IT:

1) Для ККШ требуется стабильный рабочий процесс который выдает типовую, однородную, а в идеале - одинаковую, продукцию с некоторыми отклонениями. Например при производстве штампованных ложек, мы получим типовые штампованные ложки, и при производстве каждой ложки нам не требуется переизобретать ее заново, думать над тем как ее сделать и так далее. У нас есть стандартный производственный процесс и он повторяется из раза в раз. Между тем, в IT все не так. Практически каждая задача, какой бы повторяемой она ни была, требует осмысления, а порой и изменения способа реализации, потому что IT-ландшафт очень быстро меняется, и то что делалось одним способом вчера, сегодня уже может потребовать других действий.Контрольные карты предполагают, что процесс можно удерживать в пределах нормы с небольшими отклонениями, но в IT такие отклонения могут быть значительными по размеру, и это является обычным делом для данной области.

2) Эдвард Деминг постулировал, что контрольные карты Шухарта нужно применять для процессов, в которых результат подчиняется нормальному закону распределения. А распределение Lead Time в задачах интеллектуального труда носит отличный от нормального, асимметричный, сдвинутый влево, характер распределения, больше всего похожий на распределение Вейбулла.

3) Lead Time может сильно варьироваться в зависимости от задачи, и эти вариации не всегда указывают на проблемы процесса, а могут быть нормальными для данного рабочего процесса и особенностей конкретной задачи. Контрольные карты Шухарта, которые рассчитаны на стабильно повторяющиеся процессы, в этом случае могут давать ложные сигналы о проблемах, тогда как в реальности это обычная вариативность для IT-процессов, которая не требует реакции.

4) Значение коэффициентов предлагаемых Шухартом для вычисления контрольных пределов могут быть недостаточны для задач интеллектуального труда, так как для них характерна гораздо бОльшая вариативность, чем в материальном производством. Есть риск, что вычисленные с использованием этих коэффициентом контрольные пределы будут не информативны для задач разработки ПО.

Аргументы ЗА применение ККШ в разработке ПО:

1) Одной из главных задач Канбан-метода как раз и является стабилизация рабочего процесса интеллектуального труда и приведение его к статистической управляемости. По идее, мы можем выбрать такие “срезы” задач интеллектуального труда, которые будут одинаковы по своей природе, типу, классу обслуживания, и при условии постоянства состава команды разработки, работающей над задачами, мы потенциально можем получить достаточно однородный поток задач, к которому могут быть применены контрольные карты Шухарта.

2) Шухарт всегда опирался на эмпирические данные, и не привязывался к тому, какое именно распределение - нормальное или нет - характерно для этих данных. В 1967 году Ирвин Барр провел расчеты более чем для 20 разных распределений отличных от нормального, и убедительно показал, что коэффициенты Шухарта для вычисления контрольных пределов отлично работают при любом из этих распределениях (Irving W. Burr "The effect of non-normality on constants for X and R charts")

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

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

В ходе подготовки статьи, я нашел несколько статей на ResearchGate и других источниках, где приводятся примеры попыток применения статистического контроля качества в ИТ, и в том числе, применения контрольных карт Шухарта.

Одна такая статья меня заинтересовала больше других. Называется она Statistical Process Control for Software: Fill the Gap

Авторы этой статьи предлагают использовать XmR диаграмму Lead Time разработки программного обеспечения для контроля рабочего процесса, но не для того, чтобы отслеживать отклонения рабочего процесса от статистической предсказуемости, а для того, чтобы вовремя уловить тренды на отклонения от некоего равновесного, стабильного состояния которое очищено от влияния аномалий, и подвержено только общим (common) причинам вариативности.

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

Авторы предлагают следующий алгоритм действий:

1) Выбрать в качестве измеряемого параметра время поставки (Lead Time) задачи

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

3) На основе эталонных данных выбирается эталонная средняя линия CLX (central line for X) для графика X-диаграмме индивидуальных значений, которая представляет собой среднее арифметическое значений времени поставки задач в эталонный период

4) Рассчитать среднее значение размахов mR-среднее для mR-диаграммы скользящих размахов эталонного периода

5) Рассчитать значение 3σ с использование табличного коэффициента E2 из таблицы Шухарта для XmR диаграммы, который равен 2.66

3σ = 2.66 * mRсреднее

6) Расчёт контрольных пределов:

Верхний контрольный предел (UCL) = CLX + 3σ

Нижний контрольный предел (LCL) = CLX - 3σ

7) Расчитать центральную линию CLmr (central line for mR) для mR-диаграммы скользящих размахов. Она будет равна среднему значению размахов в эталонном периоде:

CLmr = mRсреднее

8) Рассчитать верхний контрольный предел скользящих размахов mR эталонного периода - UCLmr (upper control limit for mR) - используя табличное значение коэффициента D4=3.268 для XmR-диаграммы

UCLmr = 3.268 * mRсреднее

9) Нижний контрольный предел скользящих размахов mR эталонного периода - LCLmr (lower control limit for mR) - будет равен нулю, так как отрицательным он быть не может по своей природе

LCLmr = 0

10) Нанести эти контрольные пределы и центральные линии на X-диаграмму и mR-диаграмму эталонного периода, и проверить, укладываются ли все значения X и mR в рассчитанные контрольные пределы.

Если да - то эти параметры принимаются за эталонные для дальнейших наблюдений за всем процессом.

Если нет - это значит, что эталонный период выбран не верно, либо эталонные данные не очищены от аномальных значений, появившихся в результате специальных причин. В этом случае следует либо выбрать новый эталонный период, либо очистить текущие эталонные данные от значений, появившихся под влиянием специальным причин. Затем следует повторить шаги 3-9 до тех пор пока не будет установлен подходящий эталонный период.

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

12) Вместо классического подхода Шухарта для выявления нестабильности в рабочем процесса, основанного на выявления одиночных точек, которые выходят за рамки контрольных пределов, авторы статьи предлагают использовать так называемые Run-тесты, в которых выявляются систематические паттерны поведения нескольких точек относительно центральной линии, и линий одно-, двух-. и трехсигмовых пределов. Авторы подчеркивают, что этот подход более информативен для анализа процессов разработки программного обеспечения, так как показывают, что характеристики рабочего процесса подвергаются смещению, или уже сместились (shift) относительно эталонных значений. Частично я рассказывал про такие тесты в предыдущей статье про Run Chart.

В статье авторы приводят 8 Run-тестов (RT) провал которых будет являться сигналом для менеджера о том, что рабочий процесс требует его внимания:

RT1: 3σ-тест: Выход одной точки за трех-сигмовые (3σ) пределы

RT2: 2σ-тест: Две из трех последовательных точек находятся за пределами 2σ

RT3: 1σ-тест: Четыре из пяти последовательных точек находятся за границами 1σ

RT4: Серия точек под или над CLX: 7 последовательных точек находятся над или под центральной линией

RT5: Смешивание данных нескольких процессов / Сверхконтроль над процессом: 8 точек чередуются по обе стороны от центральной линии CLX, за пределами области ±1σ

RT6: Стратификация: 15 точек подряд в пределах ±1σ

RT7: Осциллирующий тренд: 14 чередующихся верхних и нижних точек подряд

RT8: Линейный тренд: 6 точек подряд, постоянно увеличивающихся или уменьшающихся

Ниже показано, как эти тесты выглядят графически:

Все эти тесты основаны на теории вероятности. Вероятность последовательности независимых событий равна произведению вероятностей этих событий. Если вероятность выхода одной точки за пределы 3σ равна 0.5 (50%) - либо выйдет, либо нет - то вероятность выхода двух последовательных точек за пределы 3σ уже равна 0,5*0,5 = 0,25 = 25%, для трех точек это значение будет равно 0.125 = 12,5%, а для 9 последовательных точек эта вероятность упадет до мизерных 0,00195 = 0,002%.

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

Для простоты анализа и наглядности предлагается разбить график линиями 1σ, 2σ, 3σ, чтобы было легко определить выход точек за конкретные пределы

13) Далее авторы дают конкретную расшифровку каждого из паттернов - как менеджеру надо их интерпретировать с точки зрения изменений рабочего процесса:

Run-тесты c 1го по 3-й надо интерпретировать как ранние сигналы о возможных изменениях в характеристиках рабочего процесса из-за специальных (assignable) причин, которые следует найти и устранить. Срабатывание теста номер 4 подает сигнал о смене среднего значения рабочего процесса. Тесты 5 и 6 указывают на случившееся увеличение или уменьшение вариативности. Тест 7 указывает на то, что на процесс влияют две систематически чередующиеся причины (например, две сменяющие друг друга команды разработчиков) и нужно разделить визуализацию их влияния, чтобы понять, что происходит. Тест 8 нужно интерпретировать, глядя одновременно и на X- и на R-график, и говорит о том, что в системе уже сейчас идет устойчивый процесс изменений его характеристик - либо в сторону улучшения, либо в сторону ухудшения

14) Авторы указывают, что в результате планомерной работы по устранению специальны причин, система будет приходить в более прогнозируемое состояние, и рассчитанные ранее контрольные пределы могут устареть и потерять актуальность, и их надо пересмотреть Авторы предлагают таблицу, которая показывает, в каких случаях нужно менять контрольные пределы:

15) И наконец, авторы показывают, какие run-тесты указывают не необходимость изменения контрольных пределов

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

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

Подведем итог

Какой бы график отображения вариативности системы мы не взяли - Scatterplot, Run Chart, Control Chart - смысл третьей Канбан-метрики в том, чтобы показать степень статистической управляемости рабочей системы и возможности прогнозировать поведение рабочей системы в будущем.

Используя Scatterplot для поиска корреляций, Run Chart для отслеживания трендов и Control Chart для контроля стабильности, менеджеры могут эффективно управлять процессами и своевременно выявлять проблемы

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

Больше материалов о полезных метриках можно найти по ссылке

Для дальнейшего погружения в теме метрик полезно почитать:

- Как руководителю победить хаос в процессах

- Customer Lead Time, System Lead Time, Cycle Time, First Touch Time - как во всем этом разобраться?!

- Как в Excel построить график распределения Lead Time и прогнозировать время с вероятностью 85%

- На что опираться при прогнозировании сроков?

PS Перепечатка даннной статьи или ее части возможна только с согласия автора