Ознакомительная версия.
Приведем пример. Отбивающий в бейсболе обладает коэффициентом ударов (известным также как средний уровень), который показывает, как часто он наносил удары, приводившие как минимум к взятию первой базы. У разных отбивающих разные коэффициенты, обычно они колеблются от 0,1 до 0,35. В любой день такой игрок может продемонстрировать показатели ниже своего среднего коэффициента ударов. Это зависит от ряда факторов: выбора питчера[13], коэффициента успешности ударов других игроков, а также от специфики подач.
Если изменить правила бейсбола так, чтобы соотношение шансов было в среднем в пользу отбивающего и не в пользу питчера, то средний коэффициент для отбивающих вырастет и лучшие игроки смогут достичь показателя, превышающего 0,5. Это пример модификации системы ради изменения случайных вариаций внутри нее.
Теперь приведем пример из области разработки. Пусть внутренняя, случайная вариация – это количество ошибок на строчку кода, требование, задачу или на единицу времени. Среднее количество, распространение и распределение ошибок или дефектов можно изменить, поменяв инструменты и процессы – допустим, введя модульное тестирование, непрерывную интеграцию и дружеские экспертизы программ.
Определение процесса, которое используется в вашей команде и выражено в виде правил, отражает правила совместной игры по разработке ПО. Они определяют источники и количество внутренних вариаций. Ирония состоит в том, что «случайные» вариации на самом деле находятся под полным контролем команды и руководства, которые могут изменять правила и процессы, тем самым влияя на источники внутренней вариативности.
Внешние источники вариативности – это события, происходящие вне зоны ответственности данной команды или ее руководителей. Это случайности, вносимые другими командами, поставщиками, потребителями, а также иные случаи «божественного вмешательства», как это называют в страховании: например, двухнедельный простой сервера, вызванный наводнением, в свою очередь, связанным с необычно сырой и ветреной погодой. Внешние источники вариативности требуют к себе особого подхода. Правила их не затрагивают, но можно учредить процесс, который эффективно справится с внешними вариациями. Отрасль знаний, относящаяся к этой сфере, называется управлением проблемами и рисками. Шухарт назвал внешние вариации «выявляемыми». Он имел в виду, что специалист (или группа специалистов) с легкостью укажет источник проблемы и даст его полное описание. Например: «Случилась буря, пошел сильный дождь, и наш сервер затопило». Вариации с выявляемыми причинами лежат вне сферы контроля конкретной команды или руководства, но их можно предсказать, составить план и разработать процедуры для того, чтобы с ними справиться.
Внутренние источники вариативности
Установленные процессы разработки ПО и управления проектами в сочетании со зрелостью организации и возможностями членов команды определяют количество внутренних источников вариативности и ее уровень.
Напомню, что Канбан – это не вариант жизненного цикла разработки ПО и не процесс управления проектами. Это метод управления изменениями, который требует перемен в существующем процессе – например, определения лимита незавершенных задач.
Метод анализа, используемый для разделения требований и подготовки их к разработке, обладает собственным уровнем вариативности. Один из источников этого – размер единиц работы. В первых работах, описывающих метод экстремального программирования, пользовательские истории характеризуются как записанное на карточке повествовательное описание функции, которая должна быть внедрена и передана конечному пользователю. Единственное ограничение – размеры карточки. Считалось, что создание пользовательской истории могло длиться от полудня до пяти недель. За пару лет в лондонском сообществе выработался шаблон написания пользовательских историй.
Как <пользователь>, я хочу <функцию>, чтобы <создать некую ценность>.
Использование шаблона привело к стандартизации написания пользовательских историй. Один из авторов такого подхода, Тим Маккиннон, в 2008 году сообщил мне, что, по его данным, в среднем на создание пользовательской истории требуется 1,2 дня, а вариативность составляет от половины суток до примерно четырех дней.
Это конкретный пример сокращения случайных вариаций при методе экстремального программирования, когда команде предлагается стандартизировать написание пользовательских историй по определенному шаблону. Тем самым Тим изменил правила игры. В исходных правилах устанавливалось, что члены команды должны писать пользовательские истории на карточках в свободной форме. Теперь же карточки сохранялись, но требовалось следовать определенному шаблону изложения. Очевидно, что подобные изменения находятся в сфере влияния и контроля местных менеджеров. Для системы они являются внутренними. Размер пользовательской истории контролируется случайными вариациями.
Смешение типов единиц работы
Когда ко всем задачам относятся одинаково, к тому же приписывая их к одному типу, наблюдается большая вариативность размеров, усилий, риска или других факторов. Разбивая задачи на определенные типы, можно по-разному работать с последними, что обеспечивает большую предсказуемость.
Например, в сообществе экстремального программирования были разработаны определения типов для разных размеров историй. Они получили названия «эпик» и «песчинка». Эпик – это более крупная история, для работы с ней может понадобиться несколько человек и не одна неделя, а песчинка – небольшая история, которую могут реализовать один или два разработчика всего за несколько часов. Приняв такую номенклатуру – «эпик», «история», «песчинка», – мы получаем три разных типа. Для каждого из них разброс вариативности будет ниже, чем если бы все задания трактовались как относящиеся к одному типу.
В обычном отделе разработки ПО может решаться несколько типов задач. Например, работа по созданию новой потребительской ценности под названием «функция», «история» или «пользовательский сценарий». (Как уже говорилось, они могут быть стратифицированы по размеру, подтипу домена или профилю риска.) Или работа по устранению «производственных ошибок» и «внутренних ошибок». А может быть, и работа по обслуживанию – «рефакторинг», «переделка архитектуры» или просто «обновление».
Операционные системы, базы данных, платформы, языки, API и сервисные архитектуры со временем меняются. Для работы с этими изменениями нужно обновлять и код.
Используя методы определения разных типов единиц работы, мы можем изменить медиану и разброс вариативности, увеличив предсказуемость в системе для конкретного типа работы.
Еще одна стратегия по увеличению предсказуемости – назначение общей WIP-мощности для отдельных типов. Например, в моей команде обслуживания в Corbis были разрешены только две единицы IT-обслуживания одновременно. Это ограничивало мощность, потраченную на API и обновления базы данных. Такая стратегия особенно полезна, когда типы разделяются по размеру или требуемым усилиям – как, например, эпик, история или песчинка. Назначив конкретную мощность для каждого типа, вы сможете поддержать чуткость системы и увеличить предсказуемость.
Представьте себе команду, использующую канбан-доску, на которой отражен лимит в два эпика, восемь обычных историй и четыре песчинки. В работе два эпика. В очереди освобождается место для обычной истории, но в бэклоге ни одна из них не готова к началу работы. Команда должна решить, начать ли работу с эпиком (или песчинкой) либо придерживаться ранее заявленных типов, что вызовет простой.
Если начать эпик, а через несколько дней в бэклоге окажется обычная история, то они не смогут сразу же приступить к работе над ней. Это увеличит разброс времени выполнения для обычных историй.
Лучше начать работу над песчинкой, которая будет окончена еще до того, как появится следующая обычная история. В данном случае отрицательное влияние отсутствует, а пропускная способность увеличивается. Однако если сотрудникам не повезет и они не смогут закончить более мелкий элемент до того, как на подходе окажется следующая история, то время выполнения для обычных историй увеличится, хотя и не так значительно, как в случае с эпиком. Возможности повысить пропускную способность стоит предпочесть предсказуемость и управление рисками, поскольку владельцы бизнеса и высшее руководство особенно ценят предсказуемость. Она порождает и сохраняет доверие, которое в agile считается высшей ценностью. Этого не произойдет, если делать больше работы с меньшей степенью надежности.
Смешение классов обслуживания
Ознакомительная версия.
