О чем эта статья
Это первая из серии статей, в которых мы вместе будем исследовать вопрос узких специалистов в Скрам-командах, теорию очередей, системную/локальную оптимизации и обучение в командах. В первой статье мы разберемся, почему фокус на индивидуальной работе и утилизации убивает скорость команды.
Все заняты, но скорость команды низкая
Недавно ко мне обратился один из моих студентов и пожаловался на сложность в формировании Цели Спринта. Каково же было мое удивление, когда оказалось, что Целей Спринта вообще несколько, а frontend опережает backend разработку на несколько Спринтов. Настоящая же проблема - низкая скорость команды. Как же так может быть, что все максимально заняты, делая свою работу, но команда неэффективна? Давайте в этом разберемся.
Занятость (утилизация) создает очереди и снижает скорость.
Давайте сделаем небольшой экскурс в теорию очередей. Не все знают, что утилизация ресурсов нелинейно влияет на длину очереди. Чем больше занят человек или команда, тем меньше остается у них времени на то, чтобы отреагировать на внезапно появившуюся работу, например, прилетевший баг, просьбу коллеги, или любую другую задачу. Таким образом, новая задача вынуждено помещается в очередь. Чем больше занятость (утилизация), тем длиннее очередь.
Вспомните Московские пробки в часы пик. Скорость движения машин начинает заметно снижаться с момента утилизации дороги более 50%. До этого движение абсолютно свободно. Когда же утилизация приближается к отметке 90% - все стоит наглухо.
Итак, быть очень занятым - значит не иметь возможности реагировать на возникающую работу. А это влечет за собой увеличение общего времени выполнения задачи, ведь Cycle Time = Queue Time (время простоя в очереди) + Service Time (время работы над задачей).
Ментальная ловушка
Итак, чем больше люди загружают себя, тем сильнее снижается скорость из-за больших очередей и медленного продвижения по ним задач. И тут приходит очередь той самой ментальной ловушки.
“Чем больше разработчики заняты, тем эффективнее команда” - ЛОЖЬ!
Это ментальная модель замыкает порочный круг, потому что фокус на индивидуальной занятости (читаем “утилизация”) лишь создает большие очереди, при этом скорость команды падает. Давайте представим очень простую систему, состоящую из трех шагов: бизнес-анализ, разработка и тестирование. И для простоты предположим, что все шаги происходят последовательно (не рекомендуется в Скраме). Утилизируя свою узкую экспертизу на каждом шаге, разработчики создают очереди, через которые должна будет пройти любая новая задача в общем случае.
В системном мышление это называется “локальной оптимизацией”. На системной диаграмме это выглядит так:
Подводим итоги
Утилизация ресурсов нелинейно влияет на длину очередей.
Чем больше степень индивидуальной занятости, тем больше очереди и ниже скорость команды.
Cycle Time = QT (Queue Time) + ST (Service Time).
Фокус на занятости разработчиков создает очереди и снижает общую скорость команды.
Наши действия часто основаны на ментальных ловушках.
Что дальше
В следующей статье я расскажу вам одну историю об одной большой команде, в которой каждый был очень занят, но разработка шла очень медленно. Также мы разберемся в других побочных эффектах очередей (сниженное качество и организационная гибкость).
Хотите подробнее узнать о роли Скрам-мастера, Владельца Продукта и том, как быстро доставлять бизнес-ценность при помощи Скрама? Добро пожаловать на сертификационные тренинги по Скраму: