Как часто должно меняться ограничение количества незавершенной работы в Kanban?
За последние 2-3 месяца к нам несколько раз приходили клиенты с просьбой добавить на Kanban доску возможность быстрого изменения ограничения на максимальное количество задач в столбце (WIP limit).
Причина простая - когда лимит на количество задач превышается, название столбца подсвечивается красным, и это становится не очень комфортно нашим глазам при ежедневной работе.
На первый взгляд - да, с точки зрения основ юзабилити, идти в настройки проекта за 5-10 кликов для того, чтобы изменить ограничение - это неправильно. Но. С точки зрения основ самого подхода к разработке, Kanban, это выглядит гораздо более правильным, объясню почему.
Для чего вообще используется ограничение на количество незавершенной работы, WIP?
В первую очередь для того, чтобы задачи не висели долгое время наполовину готовыми, ожидая пока у нас освободится время и мы сможем еще немного продвинуться по ним. Такое ожидание - одна из основных потерь, с которыми борятся Lean и Kanban. Как можно уменьшить ожидание? Сделать короче очередь задач. Как сделать короче очередь? Ввести ограничение на размер этой очереди и научиться соблюдать это ограничение, например, фокусируясь на доведении каждой задачи до конца перед тем, как взять следующую.
И что же часто происходит на практике? Ограничение превышается, по разным причинам, а проектная команда, вместо того, чтобы проанализировать проблему превышения лимита и попытаться ее исправить, идет по пути наименьшего сопротивления - увеличивает ограничение еще на пару задач, так, чтобы на текущий момент все было ок. Да, так тоже можно работать, но вот только такой подход нельзя назвать эффективным, по понятным причинам. И также, его нельзя называть Kanban. В лучшем случае - просто визуализация задач с помощью доски.
Разрабатывая Devprom, мы стараемся заложить некоторые основы методологий и подходов, поддерживаемых нашим инструментом. Это выражается различными способами, в частности, мы не даем быстрой ссылки на изменение лимитов прямо с доски задач. И мы верим, что хотя бы части команд это поможет не спрятать проблему в секундном порыве, а лишний раз задуматься, в чем ее причина и как можно эту причину устранить.
Согласны?
|
Еще интересные статьи на эту тему:
|
