Заблуждения о Канбан

Заблуждения о Канбан

Существует огромное количество путаницы и дезинформации о Kanban (далее – Канбан). Эта статья прояснит некоторые из основных заблуждений. Давайте пройдемся по ним, одно за другим.

1. Нужно выбрать между Канбан и Scrum

Самое распространенное заблуждение, которое я обнаружил, заключается в том, что люди думают, что должны выбрать между Канбаном и Scrum. Наверняка, этот вопрос задают снова (и получают ответы) где-то в Интернете прямо сейчас.

Конечно, это заблуждение, потому что они не являются несовместимыми.

Scrum – это фреймворк для разработки продукта. Это система, которая определяет роли, правила и артефакты, позволяющие небольшой команде определять и структурировать работу, необходимую для создания и улучшения продукта.

Канбан – это система для контроля, лимитирования и, в конечном итоге, улучшения потока работ через систему. Концепции Канбан могут быть применены к любому типу работ – Scrum работа по разработке продуктов, работа по управлению услугами, даже традиционная работа по управлению проектами (известная как «Waterfall» – каскадная модель или «Водопад»).

Да, Канбан может быть применен к проекту, управляемому через Водопад. Если через систему протекает работа, значит, можно применить Канбан. Нет никаких требований, что здесь должен быть Agile или Scrum, а здесь нет.

2. Нельзя делать спринты с Канбан

Другое распространенное заблуждение состоит в том, что нельзя делать спринты, если вы используете Канбан – это еще больше укрепляет миф «Канбан против Scrum». Канбан – это система, которая может применяться и накладываться на любую существующую структуру работы.

В настоящее время многие опытные практики Канбан продвигают свои системы к модели «непрерывного потока», которая не имеет формальных границ спринта. Но если вы начинаете с Канбан, ничто не мешает вам делать это в спринтах.

3. Канбан подходит только для производства

Другое распространенное заблуждение состоит в том, что, поскольку в Канбане нет спринтов (опять же, это не так), он не очень для хорош для долгосрочного планирования. И поэтому его следует использовать только для поддержки производства, а не для развития.

Это не так, и основано на других заблуждениях. Канбан может применяться к любой системе, через которую проходит работа, будь то поддержка, улучшение, обслуживание, разработка и т.д. Его можно использовать для небольших или крупных проектов, разработки программного обеспечения, управления производством, управления запасами (откуда он пришел) или для предоставления услуг.

4. Явная политика означает, что Канбан негибкий

Некоторые люди думают, что, поскольку Канбан требует, чтобы политика была явной, он «высечен в камне». Нет ничего более далекого от правды.

Канбан – это основа оптимизации процессов и постоянного улучшения. Важно четко указать политику: она обеспечивает прозрачность и всеобщую согласованность, а не скрытые правила и секретные лазейки, которыми управляются многие организации.

То, что политика является явной, не означает, что ее нельзя изменить. Политики и должны меняться по мере обучения и совершенствования команды. Канбан просто требует, чтобы какими бы ни были новые политики, они должны быть явными и прозрачными.

5. Канбан – это визуальные доски

Некоторые люди думают, что Канбан является синонимом визуальных досок управления (или VMB). Они приходят к выводу, что если у вас есть VMB, вы используете Канбан, а если нет, то нет. Это неправда.

Визуализация работы часто является важным шагом в путешествии по Канбану, так как она помогает командам сразу видеть очереди, блокировки, перегруженных людей, «ничейную» работу и так далее. Поэтому настройка VMB часто является одной из первых вещей, с которых команда начинает использовать Канбан.

Однако наличие VMB автоматически подразумевает, что вы используете Канбан! Но если команда ничего не делает с проблемами на своей доске, она не использует Канбан.

Настоящая цель Канбан – не визуализировать работу, а улучшить ее. И это в основном делается двумя методами:

  1. Вытягивание вместо выталкивания.
  2. Ограничение незавершенного производства (или WIP).

Если команда вытягивает работу, а не проталкивает ее, и, если они контролируют свою работу в рамках ограничений WIP, они используют Канбан. Даже если у них нет доски (хотя она, скорее всего, будет).

6. Канбан легко освоить

Существует заблуждение, что Канбан – это «легкая» или «простая» система, лучше всего подходящая для команд, которые находят Scrum «сложным». Они думают, что это своего рода «хак», чтобы получить результаты, не проходя через боль Scrum.

На самом деле здесь есть доля истины. Канбан гораздо легче начать, чем Scrum. Переход на Scrum требует серьезных изменений в том, как организация структурирует команды, выпускает программное обеспечение, работает с фондами и так далее. Многие компании не делают, не хотят или не могут вносить эти изменения, а просто назначают людям названия ролей Scrum и на этом успокаиваются. Это, конечно, приводит к «Scrumfall», «Cargo Cult Agile», «Zombie Scrum» и другим названиям из фильмов ужасов.

Начать с Канбана гораздо проще. Вы начинаете с того, что ничего не меняете и просто визуализируете работу, которая есть в системе. Однако не стоит думать, что на этом все изменения закончены.

Правильный переход в путешествие по Канбану в конечном итоге повлечет за собой множество радикальных изменений в том, как работа протекает через систему. Канбан – это система постоянных изменений и улучшений. Некоторые из них, такие как переход от системы Push к системе Pull, будут такими же сложными, как и некоторые изменения, внесенные Scrum.

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

Автор: Leon Traner

Источник