Текст книги "Масштабированный скрам. Как организовать гибкую разработку в крупной компании"

Теория массового обслуживания

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

Формальная модель для оценки процессов

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

■ Гипотеза: самый быстрый способ разработки – последовательная (каскадная или V-образная) модель с передачей больших партий от одних специализированных групп другим.

■ Гипотеза: самый эффективный способ сократить цикл разработки – максимально повысить показатели рабочей нагрузки и многозадачности для отдельных сотрудников и команд.

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

В целом эта тема относительно проста; приведенный ниже сценарий рассматривает ее ключевые аспекты.

Свойства стохастической системы с очередями

Лос-Анджелес или Бангалор в час пик. Пока каким-то чудом нет аварий, все полосы открыты для движения. Автомобили движутся плотным и медленным потоком. Затем за короткий промежуток времени происходит три аварии, и они перекрывают по одной полосе на трех основных четырехполосных магистралях. В результате из 12 полос (в совокупности) остаются открытыми только девять. Бум! Прежде чем вы успеете подумать «Почему я не купил вертолет?!», эта часть города встает в пробке. После устранения последствий аварий (на что уходит в лучшем случае от получаса до часа) проходит целая вечность, прежде чем рассосутся огромные очереди из автомобилей.

Итак, наблюдения:

■ Нелинейность. Когда автомагистраль загружена на 0–50 %, поток течет плавно – практически без задержек и очередей. Но при загруженности от 50 до 100 % замедление становится заметным, начинают образовываться очереди. Связь между загруженностью магистрали и очередями нелинейна: здесь нет плавного совместного увеличения.

■ Задержки и перегрузка начинаются намного раньше, чем достигается загрузка 99,99 %. Думаете, поток автомобилей движется быстро и плавно до тех пор, пока уровень загруженности магистрали не приближается к 100 %? Вовсе нет. Поток начинает заметно замедляться, а вероятность образования пробок резко возрастает задолго до того, как достигается максимальная загрузка.

■ Очередь образуется гораздо быстрее, чем рассасывается, – 45-минутный затор в Лос-Анджелесе в час пик создает очереди, которые сходят на нет в течение нескольких часов.

■ Стохастичность, недетерминированность. Это стохастическая система с вариативностью и вероятностными факторами, такими как интенсивность входящего потока автомобилей, время, требуемое на устранение заторов, скорость выходящего потока автомобилей и т. д.

Чтобы разобраться в поведении таких систем, требуются специальные знания, потому что, судя по всему, мы, люди, не имеем интуитивного понимания стохастических и нелинейных систем с очередями. Наоборот, интуиция заставляет нас видеть в них детерминированность и линейное поведение. Этот ложный «здравый смысл» ведет к ошибкам мышления при управлении такими системами (к которым относится и система разработки продуктов) и при анализе возникающих в них проблем. Все вышеприведенные наблюдения (в том числе и ошибки мышления) касаются и очередей НЗР в традиционной разработке, и практически всех других видов очередей.

Одна из распространенных ошибок мышления в управлении разработкой – предполагать, что очереди и люди, которые их обслуживают, ведут себя так, как показано на рис. 4.1; то есть это заблуждение, что «задержки начинаются только тогда, когда магистраль загружена на 100 %». На самом деле замедление и задержки возникают задолго до того, как будет достигнута 100 %-ная загрузка. Зачастую они могут появиться уже при 60 %-ной загрузке – и вести к заметному увеличению среднего времени цикла.

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

Но что на самом деле происходит, когда загрузка людей и всего остального в системах с вариативностью увеличивается выше некого порогового уровня?

В Xerox есть тестовая лаборатория с очень дорогостоящими большими печатными машинами. Здесь часто возникают очереди заявок на тестирование на каком-либо из этих устройств (очереди на общие ресурсы). Без понимания того, как на самом деле ведут себя эти очереди (точнее говоря, исходя из ошибочного понимания, как показано на рис. 4.1), способ их устранить кажется очевидным: обеспечить 100 %-ное резервирование и использование этих дорогостоящих машин. Но в реальности такой подход только усугубил бы проблему, потому что это стохастическая система со множеством случайных факторов: заявки на тесты поступают неравномерно, некоторые тесты быстро проваливаются, выполнение других занимает целую вечность, оборудование иногда ломается и т. д. Такая же вариативность присуща и поведению людей, и очередям работ, которые они выполняют.

Моделирование базовой системы с единичным поступлением и очередями

Как ведут себя эти системы – будь то автомагистраль, тестовая лаборатория или традиционная разработка с очередями НЗР? Вышеприведенный сценарий с дорожным трафиком дает примерное представление об этом. Математически это поведение можно смоделировать в виде вариаций системы М/М. М/М означает, что порядок поступления элементов в очередь, а также порядок обработки (обслуживания) элементов в очереди описываются случайным марковским процессом[41]41
  Марковский процесс – простая концепция, описывающая случайный (стохастический) процесс, в котором будущее состояние не детерминировано его прошлыми состояниями и не может быть предсказано на их основе; это похоже на «хаотическую реальность».


[Закрыть]. Типичная базовая модель очереди выглядит так: М/М/1/∞: один обработчик (например, один тестовый принтер или команда) и бесконечная очередь[42]42
  Очереди в разработке, как правило, не бесконечны, но это упрощение не влияет на базовый паттерн поведения системы.


[Закрыть].

Дальше начинается самое интересное. Как в системе М/М/1/∞ время цикла и время обслуживания связано с загрузкой обработчика – будь то тестовый принтер или люди, работающие с очередями НЗР? Это поведение показано на рис. 4.2 [Smith07].

График 4.2 отражает средние значения, потому что эти переменные имеют случайную вариативность, например:

■ заявки на работу поступают с нерегулярными интервалами и разного объема;

■ выполнение заявок на работу (например, на программирование или тестирование) занимает разное время;

■ люди могут работать быстрее или медленнее, больше или меньше времени, могут заболеть и т. д.

Еще один существенный момент, который следует понять, состоит в том, что элемент (новая заявка на работу) поступает в очередь и начинает ждать обслуживания задолго до того, как люди будут загружены на 100 %. Также обратите внимание, как влияет увеличение загрузки людей на продолжительность цикла: при возрастании загрузки обработчика в системе с большой вариативностью среднее время цикла увеличивается, а не уменьшается. Это полностью противоречит «здравому смыслу» традиционных менеджеров и консультантов, которые были обучены «повышать продуктивность путем увеличения утилизации ресурсов». Большинство из них не знакомы с теорией массового обслуживания и не понимают, как ведет себя стохастическая система с очередями (где люди выполняют работу с высокой вариативностью), поэтому это заблуждение продолжает так упорно сохраняться в мире менеджмента.

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

Моделирование системы с пакетным поступлением и очередями (традиционная разработка)

Дальше становится еще интереснее (сейчас увидите сами). Базовая система М/М/1/∞ подразумевает, что элементы (запросы на анализ, разработку, тестирование и т. д.) поступают по одному – никогда не группируются и не объединяются в пакеты. Но в традиционной разработке заявки на работу почти всегда поступают большими пакетами (партиями), такими как набор требований для разработки, задач на тестирование или кусков кода для интеграции. Иногда «единичное» требование, например «обеспечить поддержку HSDPA», может по факту представлять собой объемный пакет подтребований[43]43
  «Одно большое требование как пакет» – важный момент, к которому мы еще вернемся в этой главе.


[Закрыть].

Возможно, это очевидно, но мы считаем необходимым сказать это:

Увеличение размера рабочих элементов или пакетов ведет к увеличению вариативности.

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

Как такое увеличение вариативности размера влияет на очереди и время ожидания? Теперь вместо простой модели с единичным поступлением M/M/1/∞ (где элементы поступают в очередь по одному) мы имеем систему M^[x]/M/1/∞ (где в очередь поступают группы элементов или партии). Эта модель лучше всего отражает, что происходит при традиционной разработке. Ее поведение проиллюстрировано на рис. 4.3.

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

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

В таблице ниже приведена усредненная ситуация:

Теперь предположим, что при такой же 50 %-ной загрузке команда получает рабочие пакеты гораздо большего размера или «единичные» гигантские требования, которые по факту представляют собой большие пакеты подтребований; такие пакеты также поступают с некоторой неравномерностью и могут немного отличаться в размерах. Предположим, что на выполнение одного пакета X или «единичного» большого требования у команды уходит 20 недель.

Опираясь на предыдущую таблицу, многие люди спрогнозировали бы ситуацию так:

Интуиция подсказывает, что время цикла увеличится линейно. Если пропускаемая через систему партия работы увеличивается в 10 раз, значит, и время на ее выполнение возрастает в 10 раз – с 4 недель до 40.

Но все не так просто, потому что в систему вводится больше вариативности. Намного более крупная партия или более крупное «единичное» требование, состоящее из множества подтребований, привносит больше вариативности, да и сами партии могут варьироваться в размерах. Что же в таком случае происходит на самом деле?

При 50 %-ной загрузке отношение времени цикла к времени обслуживания в системе М^[x]/М/1/∞ в действительности равно 5 (а не 2). В результате мы получаем ситуацию, которая сильно отличается от приведенного выше предположения:

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

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

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

Серии очередей НЗР усугубляют задержки – и эти задержки усугубляются еще больше в традиционной последовательной разработке, поскольку здесь есть серии процессов с очередями НЗР перед ними; это дополнительно увеличивает вариативность и негативное влияние на общее среднее время цикла. Закон распределения вариативности [HS08] показывает, что худшее место для вариативности в плане негативного воздействия на время цикла – на входе в многоступенчатую систему с очередями. Это как раз то, что происходит в традиционной разработке на первом этапе анализа требований с большими пакетами спецификаций.

Заключение

Итак, что мы узнали?

■ Продуктовая разработка – это стохастическая система с очередями; она нелинейна и недетерминированна.

■ Поведение стохастической системы с очередями противоречит нашему интуитивному пониманию.

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

■ Размер очередей влияет на время цикла.

■ В вариативной системе высокий уровень загрузки увеличивает продолжительность цикла и снижает пропускную способность – традиционный подход к управлению ресурсами (фокус на бегунах, а не на эстафетной палочке) здесь не только не работает [например, McGrath04], но и может, наоборот, ухудшить ситуацию.

■ В вариативной системе с серией процессов с очередями НЗР задержки усугубляются еще больше, что характерно для традиционной последовательной разработки ПО.

■ Высокая вариативность на входе многоступенчатой системы с очередями оказывает наиболее сильное негативное влияние.

Скрытые партии: развивайте чутье на партии

Если вы печете одновременно три вишневых пирога, очевидно, что это партия из трех пирогов. Но в разработке продуктов все не так очевидно: что такое «единичное» требование? На одном уровне «цветной принтер с разрешением печати 600 DPI и скоростью печати 12 с./мин» – это одно требование, но на другом уровне это составное требование или пакет подтребований, который может быть разделен на части, такие как «цветной принтер с разрешением 600 DPI». Декомпозиция требований особенно актуальна (и легко выполнима) при разработке программных систем. «Одно» требование – особенно в больших программно-интенсивных встраиваемых системах – почти всегда представляет собой набор более простых и мелких подтребований. Вы должны уметь видеть эти скрытые партии.

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

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

Скрытые очереди: развивайте чутье на очереди

Когда люди приходят в Toyota, их учат развивать «чутье на потери». Видеть потери там, где они их раньше не видели, – например, в запасах или очередях. В результате люди мгновенно обращают внимание на очередь из любых физических вещей и воспринимают ее как проблему: «Да здесь накопилась целая куча (очередь) этих вещей! Какую пользу приносит эта куча? Возможно, там есть дефекты? Что нужно сделать с этими вещами, чтобы они были готовы к поставке? Действительно ли нам нужна каждая вещь – и мы сможем заработать деньги на каждой вещи в этой куче?»

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

Однако эти очереди – очереди НЗР в виде информации, документации и битов на компьютерном диске – существуют; они реальны, хотя и невидимы. Люди в разработке ПО должны научиться видеть эти очереди, воспринимать их как болезненную проблему и стремиться уменьшать их размеры.

Визуальное управление, чтобы сделать очереди осязаемыми[44]44
  В этом разделе мы намеренно повторяем фрагмент из главы «Бережливый подход».


[Закрыть]. Чтобы обострить «чутье на очереди» и улучшить управление ими, в бережливом подходе для представления очередей используются физические средства (а не цифровые в компьютерной программе)[45]45
  Физические визуальные средства (карточки) – критически важный аспект бережливого визуального менеджмента, который часто недооценивается. Использование для этого компьютерных программ лишает визуальное управление его главного смысла.


[Закрыть]. Например, популярная практика в скраме и других гибких методах разработки – записывать все задачи на текущий спринт на бумажных карточках, которые размещаются на стене и перемещаются по мере выполнения задач (рис. 4.4). Как мы уже говорили, людям нужно видеть и чувствовать очереди, потому что на протяжении сотен тысяч лет эволюции мы привыкли иметь дело с материальными, осязаемыми вещами. Отображение задач только в цифровой форме на компьютере не позволяет задействовать это человеческое качество и значительно снижает эффективность визуального менеджмента[46]46
  Когда появятся компьютерные мониторы размером со стену, на которых можно будет манипулировать объектами с помощью жестов, мы пересмотрим эту точку зрения.


[Закрыть].

Попробуйте… использовать визуальное управление, чтобы видеть невидимые очереди.

Косвенные преимущества уменьшения размеров партий и времени циклов

«Зачем это нужно? Наши клиенты не хотят релизов каждые две недели и не хотят поставки одного подтребования».

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

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

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

■ Последнее, но не менее важное: это приносит косвенные преимущества благодаря эффекту «камней на дне озера», описанному ниже.

Косвенные преимущества: «камни на дне озера»

В бережливом подходе используется метафора, известная как «камни на дне озера». Глубина озера – это объемы запасов, размеры партий, длина итераций или продолжительность циклов. Камни на дне озера – слабые места и источники неэффективности в системе. Когда озеро глубокое (большие объемы запасов, размеры партий, время циклов), эти подводные камни остаются незаметными. Например, если группа использует последовательную разработку с 18-месячным циклом релиза и с поэтапной передачей больших партий НЗР, все проблемные места в тестировании, интеграции, взаимодействии и т. д. остаются глубоко скрытыми под «поверхностью» длинного цикла и огромных партий. Но когда мы приходим в такую группу и предлагаем ей резко уменьшить глубину озера – перейти к созданию небольших наборов потенциально готовой к поставке новой функциональности каждые две недели, то все ее неэффективные практики со всей болезненной очевидностью выходят на поверхность.

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

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

Диаграмма причинно-следственных связей на рис. 4.5 иллюстрирует эффект «камней на дне озера» в терминах модели системной динамики.