Доска задач и лимиты WIP

Разбираемся, почему доска — это не «список дел на стене», а инструмент, который показывает, где команда стоит, и почему брать три задачи сразу хуже, чем одну.

WIP (work in progress, «работа в процессе») — количество задач, которые команда одновременно держит начатыми, но не доведёнными до конца. Лимит WIP — договорённость: больше стольких-то карточек в колонке быть не может.

Зачем вообще доска

Список задач в трекере отвечает на вопрос «что нам надо сделать». Доска отвечает на другой вопрос — «где сейчас застряла работа». Это разные вещи. В списке двадцать пунктов выглядят как двадцать пунктов. На доске те же двадцать карточек мгновенно показывают: восемь из них зависли в колонке «Ревью», а разработчики тем временем начали ещё три новые.

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

Колонки: поток слева направо

Колонки — это не «статусы для отчёта», а реальные этапы, через которые проходит задача от идеи до пользователя. Минимальный честный набор для команды разработки выглядит примерно так:

Backlog     To Do (5)   In Progress (3)  Review (2)   Testing (2)   Done
---------   ---------   ---------------  ----------   -----------   ---------
#412        #398 Аня    #401 Аня         #395 Пётр    #390          #388
#415        #399        #402 Пётр        #397 Аня                   #391
#419                    #405 Ким                                    #394
#423
#427
...ещё 60

Цифра в скобках — лимит WIP для этой колонки. В In Progress помещается три карточки, и всё: четвёртую туда просто некуда положить.

Важное правило, которое команды нарушают чаще всего: карточка движется только вправо. Если задача «вернулась» из тестирования в разработку — это не откат стрелочки назад, это сигнал. Раз в спринт посмотрите, сколько карточек вернулось: три возврата из пяти задач означают, что сломан не тестировщик, а ваше определение готовности.

Что значит «готово» в каждой колонке

Каждый переход между колонками должен иметь чёткий критерий, иначе карточки будут переезжать «на глаз». Например:

Переход	Критерий
Backlog → To Do	Задача разобрана, есть критерии приёмки, понятно, кто заказчик
To Do → In Progress	Свободен слот WIP, задача взята конкретным человеком
In Progress → Review	Код написан, тесты зелёные, PR открыт
Review → Testing	PR одобрен и влит в основную ветку
Testing → Done	Проверено на стенде, соответствует критериям приёмки

Почему «взял сразу три задачи» — вред

Разработчику это кажется разумным: пока первая задача ждёт ревью, можно не сидеть без дела и начать вторую. Логика простая — не простаивать. Проблема в том, что личная занятость и скорость команды — не одно и то же.

Есть закон Литтла (Little's law), формула из теории очередей: среднее время прохождения задачи = число задач в работе ÷ пропускная способность. Разберём на цифрах. Команда стабильно закрывает 5 задач в неделю. Если в работе одновременно висит 5 задач, средняя задача проходит путь за неделю. Если команда наберёт 20 задач сразу — пропускная способность не вырастет (людей-то столько же), а время прохождения станет 20 ÷ 5 = 4 недели.

То есть от того, что вы начали больше, вы не сделали больше. Вы просто сделали каждую задачу вчетверо дольше — и вчетверо позже узнали, что в ней ошибка.

К этому добавляются вещи, которых в формуле нет:

Переключение контекста. Возврат в задачу после двух дней в другой требует заново поднять в голове весь контекст. Полчаса-час на каждое переключение — это не преувеличение.
Конфликты в коде. Три недоделанные ветки одного человека расходятся с основной, и мержить их потом больно.
Обратная связь приходит поздно. Если задача три недели лежит в ревью, замечание «ты сделал не то» прилетает через три недели.
Ревью никто не делает. Все заняты своим — и колонка Review распухает. Классический затор.

Как работает лимит WIP

Лимит — это не запрет работать. Это принудительное переключение приоритета. Когда колонка In Progress забита под лимит, а Аня закончила задачу, она физически не может взять новую. Что ей остаётся? Посмотреть влево — а там в Review висят чужие PR. Аня идёт делать ревью, затор рассасывается, поток идёт.

Отсюда главное правило Канбана, которое звучит контринтуитивно: «Остановить начинать, начать заканчивать» (stop starting, start finishing). Приоритет всегда у карточки, которая правее.

Как выбрать число

Универсального ответа нет, но есть работающая эвристика: начните с число разработчиков + 1 для колонки In Progress. Пятеро в команде — лимит 6. Дальше смотрите: если люди регулярно упираются в лимит и ждут — либо у вас затор правее, либо лимит занижен. Если лимит никогда не достигается — он бесполезен, снижайте.

Лимит на колонки ревью и тестирования обычно ставят жёстче (2–3), потому что именно там копятся заторы.

Cumulative flow diagram

Доска показывает «сейчас». Диаграмма накопленного потока (CFD, cumulative flow diagram) показывает историю: по горизонтали — дни, по вертикали — количество задач, а закрашенные полосы — сколько задач в какой колонке было в каждый день.

задач
  60 |                                    ____ Backlog
     |                          _________/
  40 |            _____________/
     |      _____/
  20 |  ___/    ############### Review (полоса расширяется!)
     | /       ///////////////  In Progress
   0 |________________________________________ Done
     пн     пт     пн     пт     пн     пт

Читается диаграмма просто, по толщине полос:

Полоса расширяется — в эту колонку задачи входят быстрее, чем выходят. Это и есть затор. На картинке выше распухает Review — значит, команда пишет код быстрее, чем успевает его проверять.
Полоса ровная — вход и выход сбалансированы, поток здоровый.
Полоса Done не растёт — команда неделю что-то делает, но наружу ничего не выходит.
Вертикальная толщина всех «незавершённых» полос — это и есть текущий WIP. Горизонтальный «пробег» карточки между линией входа и линией выхода — время прохождения.

Блокеры на доске

Блокер — это задача, которая не движется не потому, что её никто не делает, а потому что делать её нельзя: ждём доступ, ждём ответ юриста, упали внешние API. Такие карточки помечают отдельно (красная наклейка на физической доске, флажок в трекере) — и это должно быть видно с трёх метров.

Работающие договорённости про блокеры:

Блокер помечают в момент возникновения, а не на стендапе. Ждать до утра — потерять полдня.
На карточке пишут дату блокировки. «Заблокирована 3 дня» — это уже разговор, а не жалоба.
Блокер не освобождает слот WIP. Иначе появляется соблазн «пометить красным и взять новую» — и WIP тихо растёт.
Правило эскалации. Например: блокер старше двух дней Scrum-мастер выносит наружу — к руководителю смежного отдела, к вендору, к кому угодно. Это буквально его работа.

Раз в месяц полезно посмотреть, что вас блокировало чаще всего. Если из десяти блокеров шесть — «ждём доступ от админов», проблема не в конкретных задачах, а в процессе выдачи доступов, и лечить надо его.

Как это работает

Соберём в одну картину. Доска делает поток видимым. Лимит WIP не даёт потоку захлебнуться: он превращает «все заняты» в «работа движется». Закон Литтла объясняет, почему меньше начатого = быстрее готовое. CFD показывает, где затор копится не сегодня, а системно. Блокеры отделяют «мы не успели» от «нам не дали».

Ключевая метрика, ради которой всё это делается, — время прохождения (lead time): сколько дней проходит от момента, когда задачу взяли в работу, до момента, когда она в проде. Не количество задач и не занятость людей. Именно эти дни чувствует на себе заказчик.

Частые ошибки

Колонки, не отражающие реальность. На доске три колонки, а на деле есть ещё «ждём аналитика» и «ждём релизного окна» — они просто не нарисованы, и заторы в них невидимы. Рисуйте те этапы, которые есть, даже некрасивые.
Лимит WIP нарисован, но нарушается. «Ну эта задачка срочная, положим четвёртую». Через месяц лимит — просто цифра в заголовке. Лимит либо соблюдается, либо его нет.
Колонка «Готово», из которой ничего не выходит. Если Done означает «код влит», но релиз раз в квартал — вы обманываете себя. Готово — это «у пользователя».
Персональные дорожки. Доску делят на строки по людям, и каждый тянет свою. Это убивает саму идею общего потока: помогать соседу становится не с руки.
Доска ради стендапа. Карточки двигают за пять минут до созвона. Тогда доска показывает не поток, а ритуал.
Лимит поставили только на In Progress. Разработка перестала захлёбываться, а всё скопилось в тестировании. Затор просто переехал.

Итоги

Доска показывает движение задач, а не занятость людей.
Колонки — реальные этапы потока; карточка движется слева направо, и каждый переход имеет критерий.
Закон Литтла: время прохождения = WIP ÷ пропускная способность. Больше начатого — не быстрее, а дольше.
Лимит WIP заставляет доделывать чужое, прежде чем брать своё: stop starting, start finishing.
Стартовая эвристика лимита для In Progress — число разработчиков + 1; на ревью и тестирование лимит жёстче.
CFD показывает, какая полоса расширяется, — там и системный затор.
Блокеры помечают сразу, с датой, они не освобождают слот WIP и эскалируются по правилу.