В IT-компаниях периодически возникает спор, который выглядит как принципиальный выбор: мы работаем по Agile или внедряем теорию ограничений? Это сложный момент, потому что ТОС и Agile отвечают на разные вопросы, и противопоставлять их, все равно, что спорить о том, что важнее для автомобиля, двигатель или руль. Разберем, где между ними реальный конфликт, а где они усиливают друг друга.
Коротко суть каждого
Agile — это инструмент, который позволяет понять, как доставлять ценность небольшими итерациями, быстро получать обратную связь и не пытаться спланировать все на год вперед. Спринты, бэклог, ретроспективы, инкременты — механика про скорость обучения и адаптацию.
Теория ограничений Голдратта — это про то, как смотреть на систему целиком. Ее центральная идея заключается в том, что в любой системе есть одно ограничение (узкое место), которое определяет пропускную способность всего потока. Улучшать что угодно, кроме ограничения, значит тратить силы впустую, потому что общий результат от этого не вырастет. Сначала находим ограничение, потом подчиняем ему все остальное.
Уже из определений видно, что Agile говорит, как организовать работу команды, а ТОС — куда направить усилия, чтобы вырос результат всей системы. Это разные уровни, и в этом все дело.
Где кажется, что они конфликтуют
При поверхностном анализе обеих теорий кажется, что между ними есть противоречия, и из-за этого рождается ложная дилемма. Agile не любит жесткого планирования, а ТОС с ее критической цепью выглядит как возврат к плановости. Agile фокусируется на команде и ее автономии, а ТОС смотрит на сквозной поток через все команды и отделы. Agile измеряет скорость работы отдельной команды, ТОС интересует пропускная способность всей цепочки до клиента.
Эти противоречия реальны ровно до тех пор, пока вы смотрите на оба подхода как на конкурирующие методологии управления. Как только вы признаете, что они про разное, конфликт исчезает.
Где они на самом деле дополняют друг друга
Главная польза от их сочетания состоит в том, что Agile прекрасно ускоряет отдельную команду, но ничего не говорит о том, та ли это команда, которую надо ускорять. Можно героически поднять скорость разработки, а потом обнаружить, что готовые фичи неделями ждут тестирования или ревью, и до клиента все доходит ровно с той же скоростью, что и раньше. Команда работает быстрее, а поток не изменился.
Вот здесь и нужна оптика ТОС. Она задает вопрос уровнем выше: где в нашем сквозном потоке, от идеи до работающей у клиента функции, то самое узкое место? Если это тестирование, то ускорять разработку бессмысленно, вы просто увеличите очередь перед тестированием. Сначала нужно работать с ограничением, а Agile-механики применять там, где они дадут эффект для всего потока, а не для локальной метрики одной команды.
Пять шагов фокусировки
У ТОС есть короткий алгоритм из пяти шагов, и он на удивление хорошо ложится на разработку.
- Найти ограничение.
- Решить, как выжать из него максимум без вложений: например, не нагружать дефицитного тестировщика тем, что в состоянии сделать кто-то другой, и не отвлекать его на мелочи.
- Подчинить ограничению всю остальную работу, то есть не заваливать узкое место задачами быстрее, чем оно успевает их обработать. Здесь, кстати, есть прямая связь с Agile-практикой ограничения незавершенной работы (WIP-лимиты): это ровно то же самое требование, только сформулированное на языке доски задач.
- Расширить ограничение, если первых трех шагов оказалось мало: нанять, автоматизировать, перестроить процесс.
- И последний шаг, о котором чаще всего забывают: как только ограничение перестало быть ограничением, вернуться к началу, потому что узкое место уже переместилось в другую точку.
Это и есть непрерывное улучшение, и оно прекрасно живет в ритме спринтов и ретроспектив.
Критическая цепь и спринты
Отдельно стоит упомянуть про управление проектами. В ТОС есть свой метод — Critical Chain Project Management (CCPM), его обычно противопоставляют спринтам, хотя они решают разные задачи. CCPM борется с типовой болезнью оценок: люди закладывают запас времени в каждую задачу на всякий случай, а потом этот запас все равно используется. CCPM убирает скрытые буферы из отдельных задач и собирает их в один общий буфер проекта, которым осознанно управляют.
В активной IT-компании это сочетается со спринтами без особого труда. Спринт остается ритмом работы команды, в то время как буферное мышление ТОС применяется на уровне сквозной поставки: вы защищаете буфером не каждую задачу, а критический путь до релиза, и следите за тем, как этот буфер расходуется. Спринты дают ритм, ТОС защищает срок поставки в целом.
Стоит честно сказать и про сопротивление, потому что главная сложность тут не методологическая, а человеческая. Каждый руководитель отдела привык отвечать за свою метрику и свою загрузку. Идея ТОС, что некоторым участкам надо сознательно работать не на полную мощность ради пропускной способности всей системы, противоречит привычке загружать всех по максимуму. Тестировщик-ограничение должен быть занят на сто процентов, а вот команда перед ним — нет, иначе она просто наращивает очередь. Объяснить это людям, которых годами премировали за личную загрузку, труднее, чем нарисовать любую диаграмму потока. Без поддержки сверху локальная оптимизация побеждает почти всегда.
Как это выглядит на практике
Сведем к простому порядку действий для IT-руководителя. Сначала нарисуйте сквозной поток — не процесс одной команды, а весь путь от запроса до работающей функции у клиента, со всеми передачами между командами. Почти всегда именно на стыках, в очередях между этапами, и прячется потеря времени. Затем найдите, где скапливается работа: узкое место видно по очередям — где задачи дольше всего ждут, там и ограничение. Это может быть вовсе не разработка, а тестирование, ревью, согласование с безопасностью или приемка со стороны бизнеса.
Дальше расширяйте именно ограничение, а не то, что удобнее. Соблазн велик: оптимизировать то, что измеряется и где есть привычные инструменты. ТОС требует дисциплины работать именно с ограничением, даже когда это неудобно. И применяйте Agile там, где он усилит поток: после расширения ограничение переместится в другую точку, а короткие итерации, быстрая обратная связь и ретроспективы отлично работают на постоянное обнаружение и устранение нового узкого места. По сути, цикл непрерывного улучшения ТОС и культура ретроспектив Agile говорят об одном и том же.
Какие метрики смотреть
Сочетание подходов меняет и то, что вы измеряете. Скорость работы отдельной команды — полезная внутренняя метрика, но она почти ничего не говорит о результате для клиента. ТОС-оптика добавляет метрики потока: сколько времени проходит от запроса до работающей функции (lead time), сколько работы одновременно висит в процессе, где задачи дольше всего простаивают в очередях между этапами. Именно эти числа показывают реальное ограничение.
Бывает отрезвляюще: команда гордится растущей скоростью, а время выполнения заказа стоит на месте, потому что узкое место не в скорости написания кода, а где-то дальше по потоку. Пока вы смотрите только на один показатель скорости, вы этого не увидите и продолжите оптимизировать то, что и так не тормозит.
Простой пример
Команда из нашей практики (детали обобщены) за полгода подняла скорость разработки почти вдвое, наняв людей и внедрив крепкий Scrum, при этом время от запроса бизнеса до релиза почти не изменилось. Когда нарисовали сквозной поток, стало видно: готовый код в среднем девять дней ждал ручного тестирования, потому что тестировщик был один на три команды. Ограничением была не разработка, которую так старательно ускоряли, а тестирование. Перераспределили усилия туда (автоматизировали часть проверок, перекинули людей), и срок поставки сократился без всякого дальнейшего ускорения разработки.
Вывод
ТОС и Agile — не конкуренты и не два варианта одного выбора. Agile отвечает на вопрос, как команде эффективно работать и быстро учиться. ТОС отвечает на вопрос, где во всей системе находится ограничение, на котором надо сосредоточиться. Сильнее всего IT-компания становится, когда использует оба: ТОС наводит фокус на правильную точку, в то время как Agile дает инструменты, чтобы быстро в этой точке улучшаться. Спор «ТОС или Agile» стоит закрыть и заменить вопросом «где наше ограничение и какими инструментами мы с ним работаем».