--- md_version: 2 title: "ТОС и Agile: как совместить два подхода в IT-компании" description: "Как сочетать TOC, Kanban и итеративную работу, не объявляя WIP-лимиты и подчинение ограничению одним и тем же механизмом." canonical: "https://tesstech.ru/blog/tos-i-agile-kak-sovmestit-dva-podkhoda-v-it-kompanii/" markdown: "https://tesstech.ru/blog/tos-i-agile-kak-sovmestit-dva-podkhoda-v-it-kompanii/index.md" published: "2026-07-03" modified: "2026-09-08" author: "Tess Technology" organization: "ООО ТЕСС ТЕХНОЛОДЖИ" language: "ru-RU" category: "Операционная эффективность" direction: "operational-efficiency" tags: ["ТОС","Операционная эффективность","B2B","Стратегия"] image: "https://tesstech.ru/upload/iblock/948/mufmbttsww7stwectm0zvcykvhxx9k0d.PNG" original_source: "https://tesstech.ru/info/articles/biznes-sovety/tos-i-agile-kak-sovmestit-dva-podkhoda-v-it-kompanii/" related_service: title: "Повышение операционной эффективности" url: "https://tesstech.ru/services/the-theory-of-constraints-toc/" related_articles: - title: "DBR (Drum-Buffer-Rope): производственный метод ТОС в деталях" url: "https://tesstech.ru/blog/dbr-drum-buffer-rope-proizvodstvennyy-metod-tos-v-detalyakh/" markdown: "https://tesstech.ru/blog/dbr-drum-buffer-rope-proizvodstvennyy-metod-tos-v-detalyakh/index.md" - title: "Как ТОС помогает ускорить реализацию проектов без роста затрат" url: "https://tesstech.ru/blog/kak-tos-pomogaet-uskorit-realizatsiyu-proektov-bez-rosta-zatrat/" markdown: "https://tesstech.ru/blog/kak-tos-pomogaet-uskorit-realizatsiyu-proektov-bez-rosta-zatrat/index.md" - title: "ТОС в производстве: сокращение цикла выпуска продукции" url: "https://tesstech.ru/blog/tos-v-proizvodstve-sokrashchenie-tsikla-vypuska-produktsii/" markdown: "https://tesstech.ru/blog/tos-v-proizvodstve-sokrashchenie-tsikla-vypuska-produktsii/index.md" sources: - "https://www.tocico.org/resource/resmgr/2016_Tocico/Bulgaria/PDFSlides/TOC_An_Introduction_Bulgaria.pdf" - "https://kanbanguides.org/the-kanban-guide/" --- # ТОС и Agile: как совместить два подхода в IT-компании В IT-компаниях периодически возникает спор, который выглядит как принципиальный выбор: мы работаем по Agile или внедряем теорию ограничений? Это сложный момент, потому что ТОС и Agile отвечают на разные вопросы, и противопоставлять их, все равно, что спорить о том, что важнее для автомобиля, двигатель или руль. Разберем, где между ними реальный конфликт, а где они усиливают друг друга. **Коротко суть каждого** Agile – это инструмент, который позволяет понять, как доставлять ценность небольшими итерациями, быстро получать обратную связь и не пытаться спланировать все на год вперед. Спринты, бэклог, ретроспективы, инкременты – механика про скорость обучения и адаптацию. Теория ограничений Голдратта – это про то, как смотреть на систему целиком. Ее центральная идея заключается в том, что в любой системе есть одно ограничение (узкое место), которое определяет пропускную способность всего потока. Улучшать что угодно, кроме ограничения, значит тратить силы впустую, потому что общий результат от этого не вырастет. Сначала находим ограничение, потом подчиняем ему все остальное. Уже из определений видно, что Agile говорит, как организовать работу команды, а ТОС – куда направить усилия, чтобы вырос результат всей системы. Это разные уровни, и в этом все дело. **Где кажется, что они конфликтуют** При поверхностном анализе обеих теорий кажется, что между ними есть противоречия, и из-за этого рождается ложная дилемма. Agile не любит жесткого планирования, а ТОС с ее критической цепью выглядит как возврат к плановости. Agile фокусируется на команде и ее автономии, а ТОС смотрит на сквозной поток через все команды и отделы. Agile измеряет скорость работы отдельной команды, ТОС интересует пропускная способность всей цепочки до клиента. Эти противоречия реальны ровно до тех пор, пока вы смотрите на оба подхода как на конкурирующие методологии управления. Как только вы признаете, что они про разное, конфликт исчезает. **Где они на самом деле дополняют друг друга** Главная польза от их сочетания состоит в том, что Agile прекрасно ускоряет отдельную команду, но ничего не говорит о том, та ли это команда, которую надо ускорять. Можно героически поднять скорость разработки, а потом обнаружить, что готовые фичи неделями ждут тестирования или ревью, и до клиента все доходит ровно с той же скоростью, что и раньше. Команда работает быстрее, а поток не изменился. Вот здесь и нужна оптика ТОС. Она задает вопрос уровнем выше: где в нашем сквозном потоке, от идеи до работающей у клиента функции, то самое узкое место? Если это тестирование, то ускорять разработку бессмысленно, вы просто увеличите очередь перед тестированием. Сначала нужно работать с ограничением, а Agile-механики применять там, где они дадут эффект для всего потока, а не для локальной метрики одной команды. **Пять шагов фокусировки** У ТОС есть короткий алгоритм из пяти шагов, и он на удивление хорошо ложится на разработку. 1. **Найти ограничение.** 2. **Решить, как использовать его без дополнительных вложений:** убрать простои, неподходящую работу и потери при передаче. 3. **Подчинить остальные решения выбранному режиму работы ограничения.** Это третий фокусирующий шаг TOC: локальные решения не должны мешать использованию ограничения и результату всей системы. Контроль WIP относится к Kanban и ограничивает количество начатой, но не завершенной работы. Эти механизмы могут поддерживать друг друга, но не являются одним и тем же требованием. 4. **Расширить ограничение, если предыдущих мер недостаточно:** изменить мощность, технологию или организацию процесса. 5. **После снятия ограничения вернуться к первому шагу:** системное ограничение могло переместиться. Это и есть непрерывное улучшение, и оно прекрасно живет в ритме спринтов и ретроспектив. **Критическая цепь и спринты** Отдельно стоит упомянуть про управление проектами. В ТОС есть свой метод – Critical Chain Project Management (CCPM), его обычно противопоставляют спринтам, хотя они решают разные задачи. CCPM борется с типовой болезнью оценок: люди закладывают запас времени в каждую задачу на всякий случай, а потом этот запас все равно используется. CCPM убирает скрытые буферы из отдельных задач и собирает их в один общий буфер проекта, которым осознанно управляют. В активной IT-компании это сочетается со спринтами без особого труда. Спринт остается ритмом работы команды, в то время как буферное мышление ТОС применяется на уровне сквозной поставки: вы защищаете буфером не каждую задачу, а критический путь до релиза, и следите за тем, как этот буфер расходуется. Спринты дают ритм, ТОС защищает срок поставки в целом. Стоит честно сказать и про сопротивление, потому что главная сложность тут не методологическая, а человеческая. Каждый руководитель отдела привык отвечать за свою метрику и свою загрузку. Идея ТОС, что некоторым участкам надо сознательно работать не на полную мощность ради пропускной способности всей системы, противоречит привычке загружать всех по максимуму. Тестировщик-ограничение должен быть занят на сто процентов, а вот команда перед ним – нет, иначе она просто наращивает очередь. Объяснить это людям, которых годами премировали за личную загрузку, труднее, чем нарисовать любую диаграмму потока. Без поддержки сверху локальная оптимизация побеждает почти всегда. **Как это выглядит на практике** Сведем к простому порядку действий для IT-руководителя. Сначала нарисуйте сквозной поток – не процесс одной команды, а весь путь от запроса до работающей функции у клиента, со всеми передачами между командами. Почти всегда именно на стыках, в очередях между этапами, и прячется потеря времени. Затем найдите, где скапливается работа: узкое место видно по очередям – где задачи дольше всего ждут, там и ограничение. Это может быть вовсе не разработка, а тестирование, ревью, согласование с безопасностью или приемка со стороны бизнеса. Дальше проверяйте меры на системном показателе. TOC направляет внимание на ограничение и требует подчинить ему локальные решения; Kanban помогает управлять потоком и незавершенной работой; короткие итерации и ретроспективы дают ритм проверки. Совместимость этих инструментов не означает методологической тождественности. **Какие метрики смотреть** Сочетание подходов меняет и то, что вы измеряете. Скорость работы отдельной команды – полезная внутренняя метрика, но она почти ничего не говорит о результате для клиента. ТОС-оптика добавляет метрики потока: сколько времени проходит от запроса до работающей функции (lead time), сколько работы одновременно висит в процессе, где задачи дольше всего простаивают в очередях между этапами. Именно эти числа показывают реальное ограничение. Бывает отрезвляюще: команда гордится растущей скоростью, а время выполнения заказа стоит на месте, потому что узкое место не в скорости написания кода, а где-то дальше по потоку. Пока вы смотрите только на один показатель скорости, вы этого не увидите и продолжите оптимизировать то, что и так не тормозит. **Простой пример** Команда из нашей практики (детали обобщены) за полгода подняла скорость разработки почти вдвое, наняв людей и внедрив крепкий Scrum, при этом время от запроса бизнеса до релиза почти не изменилось. Когда нарисовали сквозной поток, стало видно: готовый код в среднем девять дней ждал ручного тестирования, потому что тестировщик был один на три команды. Ограничением была не разработка, которую так старательно ускоряли, а тестирование. Перераспределили усилия туда (автоматизировали часть проверок, перекинули людей), и срок поставки сократился без всякого дальнейшего ускорения разработки. **Вывод** ТОС и Agile – не конкуренты и не два варианта одного выбора. Agile отвечает на вопрос, как команде эффективно работать и быстро учиться. ТОС отвечает на вопрос, где во всей системе находится ограничение, на котором надо сосредоточиться. Сильнее всего IT-компания становится, когда использует оба: ТОС наводит фокус на правильную точку, в то время как Agile дает инструменты, чтобы быстро в этой точке улучшаться. Спор «ТОС или Agile» стоит закрыть и заменить вопросом «где наше ограничение и какими инструментами мы с ним работаем». **Методические источники** - [TOCICO: пять фокусирующих шагов](https://www.tocico.org/resource/resmgr/2016_Tocico/Bulgaria/PDFSlides/TOC_An_Introduction_Bulgaria.pdf) - [The Kanban Guide, May 2025](https://kanbanguides.org/the-kanban-guide/) ## Услуга по теме [Повышение операционной эффективности](https://tesstech.ru/services/the-theory-of-constraints-toc/) — Выявляем системное ограничение и настраиваем поток, чтобы увеличить результат без лишних инвестиций. ## Материалы по теме - [DBR (Drum-Buffer-Rope): производственный метод ТОС в деталях](https://tesstech.ru/blog/dbr-drum-buffer-rope-proizvodstvennyy-metod-tos-v-detalyakh/index.md) - [Как ТОС помогает ускорить реализацию проектов без роста затрат](https://tesstech.ru/blog/kak-tos-pomogaet-uskorit-realizatsiyu-proektov-bez-rosta-zatrat/index.md) - [ТОС в производстве: сокращение цикла выпуска продукции](https://tesstech.ru/blog/tos-v-proizvodstve-sokrashchenie-tsikla-vypuska-produktsii/index.md)