Standing on Bits

The current crop of Agile approaches and the Theory of Constraints have thus far been like the proverbial oil and water. Agile enthusiasts have always considered TOC as grounded in manufacturing, and thus completely inadequate to handle the peculiarities of knowledge-work, and software engineering management in particular. On the other hand, TOC practitioners, notwithstanding the decade long experience in many different fields, have a hard time accepting Agile methods, as they do not seem supported by the scientific rigor and logical reasoning that is typical of TOC; and yet they do not have a workable solution for software engineering management.

In this book we have outlined a solution that merges and takes the best of both worlds, so Agile and TOC can now co-exist, and work better together. Any other Agile or TOC concept can be leveraged on top of this solution too.

Whether you have an Agile or a TOC background, you will learn about a new way to handle software engineering management at scale.

Tendon S. Standing on Bits: Agile Software Engineering Management at Scale with the Theory of Constraints / S. Tendon, TameFlow Press / TameFlow Consulting Limited, 2022. 77 c.

Предлагается фреймворк максимизации эффективности деятельности, устраняющий основной конфликт между ценностями бизнеса и ценностями работников. Фреймворк объединяет идеи из Agile и TOC.

4 системных уровня рассмотрения:

Уровень Основной поток Метрика эффективности
Индивид Психологический Состояние потока = баланс между квалификацией и задачами
Команда Информационный Охват, частота и задержка в петлях обратной связи
Отдел Операционный Operational Throughput = WIP / Time
Бизнес Финансовый Throughput Rate = Money / Time

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

Так происходит, потому что две эти дисциплины ориентируются на управление разными потоками: TOC отвечает за финансовые и операционные потоки, а Agile (хоть явно это и не постулируется) - за информационные и психологические.

<-- Человеческая эффективность                           Финансовая эффективность -->
|   Индивид          |       Команда      |         Отдел      |        Бизнес      |
<   Психологический поток   >
					  <     Информационный поток     >
									  <      Операционный поток      >
														  <    Финансовый поток    >

Механика Agile

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

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

Нас же интересует научный подход.

Генераторы прибыли в бэклоге

Отдельные единицы работы в бэклоге вряд ли напрямую транслируются в прибыль, то есть скорее всего, они не несут прямой пользовательской ценности, за которую потребители готовы заплатить. Предлагается сгруппировать элементы бэклога в группы (MOVEs - Minimal Outcome-Value Effort), каждая из которых - это минимальный набор работ, способный принести видимую пользу потребителю и таким образом может быть конвертирован в финансовый результат (Throughput).

Категоризация MOVEs

Почему важно минимизировать усилие?

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

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

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

Приоритизация MOVEs

Поскольку каждый MOVE по определению должен приносить прибыль и к тому же может быть оценен с точки зрения финансового протока (Financial Throughput), приоритеты можно рассчитать, сравнив этот показатель и отсортировав MOVEs по убыванию. Идея в том, что первым нужно выполнить MOVE, который принесет больше денег в расчете на единицу затраченного времени.

Оценить денежную составляющую сложно, но нужно к этому стремиться. Время на разработку надежнее оценивать статистическими методами (см. Закон Литтла), а не экспертными, вроде стори-пойнтов.

Более того, время в этой формуле нужно брать вполне конкретное - время работы Ограничения системы, поскольку именно Ограничение прямо определяет выработку и, как следствие, финансовый проток. Это еще один аргумент в пользу поиска узкого места в системе создания, в дополнение к тому, что предъявляет Закон Литтла.

Поиск ограничения

Необходимо учесть три перспективы:

  1. Прошлое, чтобы понять, какие части Рабочего Процесса были исторически самыми медленными.
  2. Будущее, чтобы спрогнозировать, куда ляжет наибольшая нагрузка в надвигающемся Потоке Работ.
  3. Настоящее, чтобы определить, какое Исполнение Работы наиболее нагружено в моменте.

Ограничение Рабочего Процесса (Work Process Constraint)

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

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

Ограничение Потока Работ (Work Flow Constraint)

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

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

Перед этим ограничением также нужно разместить буфер Барабан-буфер-веревка, но только вытягивать из бэклога он будет не отдельные единицы работы (Истории), а MOVEs, т.е. Эпики.

Ограничение Исполнения Работы (Work Execution Constraint)

Это очень динамичное плавающее Ограничение, т.к. оно определяется тем, как команды прямо сейчас справляются со своим объемом работ. Управляется такое Ограничение с помощью буфера времени, заданного в стиле Critical Chain Project Management (CCPM). В начале работы над каждым MOVE необходимо рассчитать целевой объем работ (количество Work Item) и плановую дату завершения (исходя из средних оценок и доверительного интервала Flow Time). От плановой даты завершения нужно отложить буфер времени, размер которого зависит от характера распределения Flow Time. При завершении каждого Work Item нужно определить сигнал - пересчитать плановую дату завершения и посмотреть, в какое место буфера она попадает (то есть определить процент “потребления” буфера).

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

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

Управление зависимостями

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

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

Внимание к людям

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

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

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

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

Порядок внедрения

Метрики потока, Сигналы старения и Работа толпой

  1. Создать инструментарий для сбора метрик потока внутри команд
  2. Визуализировать распределение времени потока
  3. Реализовать и начать использовать Сигналы старения
  4. Работать толпой, когда получен красный сигнал старения

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

@step2:Петли обратной связи

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

@step3:MOVEs

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

@step4:Помощь Херби (поиск Ограничения)

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

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

@step5:Учитываем неожиданности

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