Kanban и Lean

2011 год: Amazon делает 1 деплой каждые 11.6 секунд - 1079 в день. Как это физически возможно? Ответ: Kanban и Lean. Маленькие задачи, ограниченный WIP, непрерывный поток. Те же принципы Toyota использовала для производства автомобилей с минимальными складскими запасами - и они работают для разработки ПО так же хорошо.

• **Toyota Production System**: WIP limits и just-in-time производство позволили Toyota стать самым прибыльным автопроизводителем - запасы на 1-2 дня вместо недель как у конкурентов
• **Spotify**: адаптировали Kanban в своих squad/tribe структурах - автономные команды с собственными досками и WIP limits, без централизованного планирования спринтов
• **GitHub Flow**: ветка -> PR -> merge -> deploy. Максимально простой flow, вдохновлённый Lean: минимум overhead, максимум скорость доставки

WIP Limits

Work In Progress (WIP) limit - это ограничение на количество задач, одновременно находящихся в работе. Toyota Production System открыла этот принцип в 1950-х: слишком много незавершённой работы одновременно замедляет систему в целом, а не ускоряет. Когда каждый разработчик ведёт 5-7 задач параллельно, фактически ни одна не продвигается быстро - постоянные контекст-свитчи убивают производительность.

WIP limit для колонки «In Progress» в 3 задачи на команду из 5 человек выглядит жёстко, но работает: если лимит достигнут, новую задачу нельзя взять, пока старая не завершится. Это создаёт давление завершать, а не начинать. Разработчик, заблокированный ожиданием code review, вынужден помочь коллеге с его задачей - иначе никто не сдвинется. Это swarm behavior: команда работает как единица, а не как набор одиночек.

Flow

Flow (поток) - это ровное, предсказуемое движение работы через систему без накопления очередей и узких мест. Метрика потока - cycle time: время от начала работы над задачей до её завершения. В хорошо настроенной Kanban системе 80% задач завершаются в пределах одного стандартного отклонения от среднего - это называется flow efficiency.

Visualizing the flow - первый шаг. Cumulative Flow Diagram (CFD) показывает количество задач в каждой колонке со временем. Расширяющиеся полосы - накопление задач в колонке, узкое место. Параллельные линии - стабильный поток. Задачи ждут code review неделями - узкое место в Review. WIP limit в Review с 5 до 2 - код начинают проверять быстрее, cycle time падает.

Continuous Delivery в Kanban

Kanban естественно приводит к Continuous Delivery: если задачи завершаются по одной небольшими порциями вместо больших релизов, деплой превращается в рутинную операцию. Amazon deployments: в 2011 году - 1079 деплоев в день (1 деплой каждые 11.6 секунд). Это стало возможным именно потому, что каждое изменение маленькое и независимое.

В Kanban нет понятия «спринт» или «релизная дата». Задача завершена - она может идти в прод. Definition of Done (DoD) определяет когда задача действительно готова: код написан, тесты зелёные, review пройден, задокументировано. Только тогда карточка перемещается в Done. Это убирает «почти готово» из словаря команды.

Lean Principles

Lean Software Development - адаптация Toyota Production System для разработки ПО. Мэри и Том Поппендик в 2003 году сформулировали 7 принципов: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, see the whole. Центральный принцип - eliminate waste: всё, что не создаёт ценность для пользователя, является потерями.

Виды потерь (muda) в разработке ПО: частично сделанная работа (незавершённые задачи - это затраченное время без отдачи), излишняя функциональность (код, который никто не использует), переключение контекстов (каждое переключение стоит 15-30 минут на восстановление фокуса), ожидания (approval processes, review очереди), дефекты (баги дорого исправлять после merge), лишняя обработка (документация которую никто не читает), частые передачи (handoffs между командами).

Ключевые идеи

• **WIP Limits**: ограничение параллельной работы создаёт давление завершать, а не начинать - команда работает как единица через swarm behavior
• **Flow**: оптимизация потока (cycle time, throughput) важнее загрузки отдельных людей - узкие места видны через CFD
• **Lean**: устранение потерь (7 видов muda) - незавершённая работа, лишние фичи, переключения, ожидания, дефекты

Связанные темы

Kanban и Lean формируют основу для современных практик delivery:

• CI/CD Pipeline — Техническая реализация Continuous Delivery - автоматизация которая делает частые деплои возможными
• Git Flow и стратегии ветвления — Trunk-based development - Git-практика, реализующая Lean принцип минимального WIP на уровне веток

Вопросы для размышления

• Если команда никогда не достигает WIP limit, значит ли это что система работает идеально или что limit слишком высокий?
• Какие виды потерь (Lean muda) наиболее распространены в командах разработки, с которыми доводилось работать?
• Чем Kanban принципиально отличается от Scrum в управлении работой - и когда каждый из них предпочтительнее?

Связанные уроки

• devops-09