Представьте, что вы отвечаете за организацию цепочки поставок и продаж в продуктовом магазине. Давайте для определенности считать, что речь идет об вкусных йогуртах. У вас есть производитель, поставляющий определенный объем продукции, есть склад (ну очень бОООльшой) и обычная магазинная витрина, откуда покупатели разбирают упаковки к себе в сумки. Она имеет конечный размер и может разместить сравнительно небольшое число упаковок продуктов. Как бы вы договорились с поставщиком об объемах регулярных поставок?
В этой системе есть WIP лимит, определяемый размерами самой витрины. Больше, чем она может вместить, ничего выложить не получится (просто некуда). Если поставлять продуктов меньше, чем раскупается, то на полке периодически не будет ничего, а значит будет потеряна прибыль и клиенты (кому понравится магазин, где ничего нет). Если заранее заказать больше упаковок, чем можно продать, скажем, за день, то складские остатки начнут увеличиваться и, как минимум, «заморозят» свободные деньги или, как максимум, со временем продукты испортятся. Важно сделать так, чтобы скорость поставок была синхронизирована со скоростью потребления.
Конечно можно попытаться компенсировать рост поставок, выкладывая в торговый зал больше упаковок (например на пол, соседнюю витрину). Однако поднимать таким образом продажи это тоже самое, как добавлять в принтер больше бумаги, в надежде на увеличение скорости печати. У системы есть свойственная ей скорость (потребления, печати и др. ), которую нельзя бесконечно стимулировать «впихивая невпихуемое». Этот подход называется проталкиванием (PUSH) когда в систему сначала «закачивают» элементы работы, а потом думают, что с этим делать.
Альтернативным вариантом является «вытягивающася» система, которая в 50е годы была подсмотрена начальником механического цеха компании Тойота Тайити Оно во время его поездки в США. По его воспоминаниям идея вытягивания (PULL) в магазине как раз в момент осмотра подобной витрины. Этот человек (к слову создатель Toyota Production System) обратил внимание, что система работает в обратную сторону: вначале покупатели разбирают продукты на полке, а уже потом сотрудники магазина пополняют со склада ровно столько, сколько было куплено за день и на основании этих данных делают заказ на склад. По его возвращении на родину этот принцип лег в основу работы с Канбан доской: вначале проверяются те элементы работы, которые расположены как можно ближе к концу процесса и только после освобождения соответствующего WIP лимита переходим к предшествующим этапам (прямо как в игре в «пятнашки»). Другими словами перед тем как начать делать что-нибудь нужное, сначала завершить то, что вам казалось нужным нужным до этого.
Принцип вытягивания нашел свое отражение не только в Канбан. Его следы также видны и в SCRUM. Так в Планировании Спринта Команда разработки сама прогнозирует задачи, которые могут быть сделаны в предстоящем спринте (вытягивание), а не автоматически получает их от Владельца продукт согласно заранее предопределенному «нормативу» или текущей необходимости (проталкивание).
Вытягивание, в принципе настроено на поддержание командой её естественного ритма, когда нет авралов и переработок (состояние потока). Конечно иногда бывают моменты когда нужно «поднажать» и достигнуть краткосрочных целей. Но принцип вытягивания помогает соответствовать долгосрочной цели, которая лучше всего написана в тексте манифеста Agile разработки программного обеспечения: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно».