Kanban и поток

Закон Литтла: срок считается делением

Формула из трёх букв, которая объясняет доску лучше любых слов: среднее время прохождения равно числу задач в работе, делённому на темп завершения. 20 задач при темпе 4 в неделю - пять недель. 8 задач при том же темпе - две недели.

Из неё следует единственный честный способ ускориться без найма: уменьшить число одновременно открытых задач. Темп завершения от количества начатого не растёт, а срок растёт прямо пропорционально. Начинать больше работы - значит удлинять срок каждой, включая ту самую срочную, ради которой всё и начали.

// Проверить это на своей команде можно за десять минут: посчитай задачи в работе и посмотри в трекере, сколько закрывалось за неделю в среднем. Деление обычно совпадает с фактическим сроком с точностью до дня-двух и очень отрезвляет.

закон Литтла

среднее время прохождения = число задач в работе / темп завершения; работает для любой устойчивой очереди

WIP-лимит: заканчивать важнее, чем начинать

WIP-лимит (work in progress) - максимум элементов, одновременно находящихся на стадии. Число пишут прямо в заголовке колонки, и взять новую задачу при исчерпанном лимите нельзя: сначала помоги закрыть то, что уже начато.

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

// Отсюда контринтуитивный вывод: простой одного человека дешевле, чем десять зависших задач. Каждая из них уже съела время и внимание, а ценность даст только в момент завершения. Поэтому на исчерпанном лимите правильное действие - идти помогать, а не начинать новое.

Два срока: заказчика и команды

Lead time считают с точки зрения заказчика: от момента, когда он попросил, до момента, когда получил. Всё ожидание в очередях сюда входит. Cycle time - от старта работы до её завершения, только сама работа.

Самое полезное число - разрыв между ними. Заявка прошла за 14 дней, а в работе была полтора - значит 12,5 дня она просто лежала, и все разговоры об ускорении программистов бессмысленны. Чинить надо очередь, приоритизацию и размер партии, а не скорость набора кода.

// Скопление задач перед одной стадией означает узкое место: она пропускает меньше, чем в неё поступает. Причина бывает в людях, в качестве входящих задач или в нестабильном стенде - сначала выясняют какая, потом лечат.

lead time

срок от запроса заказчика до поставки, включая всё ожидание

cycle time

время от начала работы над задачей до её завершения

Прогноз без спринтов

Спринтов нет, а сроки спрашивают. Ответ строят на своей же истории: берут последние сто задач, смотрят распределение времени прохождения и отвечают перцентилем. «85 процентов похожих задач проходили за 9 дней или быстрее» - это содержательный ответ, потому что несёт и оценку, и разброс.

Он честнее точечного «неделя»: сразу видно, что каждая седьмая задача займёт дольше, и это нормальное свойство потока, а не чей-то провал. Условие одно - брать сопоставимые элементы. Смешивать инциденты с плановыми доработками нельзя: у них разные распределения, и общий перцентиль не описывает ни те, ни другие.

// Отдельная дисциплина - не брать новую задачу при блокировке текущей. Иначе блокировки перестают быть видимой болью: они копятся тихо, срок растёт, а причины никто не устраняет, потому что все заняты.

Как отвечать: «Задачи копятся в колонке Тестирование. Что делаешь?»

Это узкое место: стадия пропускает меньше, чем в неё поступает, и весь поток идёт с её скоростью. Сначала выясняю причину, а не добавляю людей вслепую - не хватает рук, приходят непроверяемые задачи без критериев приёмки, нестабильный стенд, и лечение в каждом случае разное. Если причина в качестве входа, работать надо раньше по потоку, а не на самой стадии. Дальше поставил бы лимит на предыдущую колонку, чтобы очередь перестала расти: по закону Литтла срок равен числу задач в работе, делённому на темп завершения, и пока задачи копятся, срок растёт линейно, а темп не меняется. И заранее закладываю, что после расшивки ограничение переедет на следующую по слабости стадию - это не провал, а нормальный ход работы с потоком. Останавливаемся, когда время прохождения устраивает бизнес.

Кандидат ищет причину до лечения, работает с входом, опирается на закон Литтла и ожидает смещения ограничения.

На чём валятся

• −− Берут новые задачи при блокировке текущих, и лимит перестаёт работать.
• −− Пытаются ускориться, начиная больше работы одновременно.
• −− Гонятся за полной загрузкой людей вместо сокращения времени прохождения.
• −− Обвиняют исполнителей узкой стадии вместо разбора причины ограничения.
• −− Дают точечную оценку срока вместо перцентиля по своей истории.
• −− Смешивают в статистике инциденты и плановые доработки.