Вы, наверное, слышали о методологии управления проектами Kanban, но, возможно, вы мало что знаете об этом. Каковы различия между Kanban и другими гибкими методологиями, такими как Scrum , и такими инструментами, как диаграмма Ганта ? Для чего используется методология Канбана?
Давайте посмотрим на происхождение Канбан, ответим на эти вопросы и посмотрим, как он используется на практике.
Основные принципы методологии канбан
Термин Kanban происходит из Японии благодаря производственной системе Toyota , которая хорошо известна в узких кругах. Было бы замечательно, если бы все знали о методологии Kanban и ее основных принципах: бережливое производство, постоянное развитие, ориентация на клиента и т. Д. Все эти принципы описаны в книге Тайити Оно « Система производства Toyota: за пределами крупномасштабного производства» .
Термин Канбан имеет дословный перевод. «Кан» означает видимый или визуальный, а «бан» означает карту или доску. Карты методологии Kanban используются на всех заводах Toyota для упрощения управления запасами — нет загроможденных складов и мастерских с достаточным доступом к деталям.
Представьте, что в вашей мастерской устанавливаются двери Toyota Corolla, а рядом с вашим рабочим пространством находится пакет из 10 дверей, которые устанавливаются одна за другой на новые автомобили. Когда в упаковке всего пять дверей, вы знаете, что пришло время заказывать новые двери. Поэтому вы берете карту Канбан, пишете заказ еще на 10 дверей и приносите карту в мастерскую, которая производит двери. Вы уверены, что новые двери будут изготовлены к тому времени, когда вы использовали оставшиеся пять дверей.
Вот как это работает в мастерских Toyota: когда вы устанавливаете последнюю дверь, приходит еще одна упаковка из 10 дверей. Вы постоянно заказываете новые двери только тогда, когда они вам нужны.
Теперь представьте, что эта система Канбан работает по всему заводу. Там нет складов с запасными частями, которые лежат в течение нескольких недель или месяцев. Все сотрудники работают по заявкам и производят только необходимое количество запчастей. Если заказов больше или меньше, система сопоставит изменения.
Основная идея карт методологии Канбан заключается в том, чтобы сократить объем незавершенного производства . Например, в соответствии с методологией Kanban для всей производственной линии может быть выдано только 10 карт для дверей. Это означает, что только 10 готовых дверей будут находиться на линии в любой момент производственного цикла. Решение, когда эти двери заказаны, является задачей для тех, кто их устанавливает. Всегда ограничено 10 дверьми, только установщики знают о предстоящих потребностях мастерской и могут размещать заказы у производителя дверей.
Эта методология бережливого производства была впервые внедрена в Toyota, но многие компании во всем мире приняли ее. Но эти примеры относятся к производству, а не к разработке программного обеспечения.
Как методология Kanban работает для разработки программного обеспечения?
Давайте начнем с рассмотрения различий в планировании проекта между Kanban и другими гибкими методологиями.
Разница между методологией Канбан и SCRUM заключается в том, что:
- В Канбан нет временных рамок ни для чего (ни для задач, ни для спринтов)
- Задачи в методологии Kanban больше, и их меньше
- Оценки периода в Канбан не являются обязательными, или их нет вообще
- В Канбан нет «скорости команды» — учитывается только среднее время для полной реализации
Теперь посмотрите на этот список и подумайте: что останется от гибкой методологии, если мы уберем спринты, увеличим размеры и перестанем считать скорость работы команды? Ничего?
Как вообще можно говорить о каком-либо наблюдении за развитием, если все основные инструменты контроля удалены? Это, наверное, самый важный вопрос для меня в методологии Канбана.
Менеджеры всегда думают о контроле и пытаются его достичь, хотя на самом деле его нет. Надзор менеджера за процессом развития — фикция. Если команда не хочет работать, она провалит проект, несмотря на любой уровень контроля.
Если команда получает удовольствие от работы и работает с полной эффективностью, тогда контроль не нужен, потому что это только мешает процессу и увеличивает затраты.
Например, общей проблемой методологии SCRUM являются более высокие затраты из-за дискуссий, встреч и больших потерь времени на стыках спринтов, когда по крайней мере один день тратится впустую для завершения спринта и еще один день для начала другого. Если спринт длится две недели, то два дня из двух недель составляют 20%, что чертовски много. Таким образом, при использовании методологии SCRUM примерно 30-40% времени тратится на поддержку самого процесса, включая ежедневные митинги, ретроспективы спринтов и так далее.
Методология разработки Kanban отличается от SCRUM тем, что фокусируется на задачах. Основная цель команды в SCRUM — успешное завершение спринта. В методологии Канбана задачи занимают первое место. Нет никаких спринтов, и команда работает над задачей от начала до конца. Развертывание производится, когда оно готово, на основе представления выполненной работы. Команда, которая следует методологии Канбана, не должна оценивать время для выполнения задачи, поскольку в этом нет никакого смысла, и эти оценки почти всегда неверны.
Зачем руководителю нужна оценка времени, если он или она верит в команду? Задача менеджера, использующего методологию Канбана, заключается в создании пула задач с приоритетами, а задача группы — выполнить как можно больше элементов из этого пула. Вот и все. Там нет необходимости каких-либо мер контроля. Все, что нужно сделать менеджеру, это добавить элементы в пул или изменить их приоритет. Это способ, которым менеджер Kanban управляет проектом.
Команда работает с доски Канбан. Это может выглядеть так:
Столбцы слева направо на доске Канбан:
- Цели : это необязательная, но полезная колонка на доске Канбан. Цели проекта на высоком уровне могут быть размещены здесь, чтобы все в команде знали о них и могли регулярно напоминать о них. Примерами целей могут быть «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7».
- Очередь историй . В этом столбце рассматриваются задачи, готовые к запуску. Старшая карта (которая имеет наивысший приоритет) берется первой, а ее карта перемещается в следующий столбец.
- Разработка и принятие . Этот столбец и все остальные столбцы, предшествующие столбцу «Готово», могут отличаться в зависимости от рабочих процессов отдельных групп. Задачи, которые обсуждаются — например, неопределенный дизайн или кодовый подход, который необходимо доработать — можно разместить здесь. Когда обсуждение закончено, оно перемещается в следующий столбец.
- Разработка : задача живет здесь до тех пор, пока разработка функции не будет завершена. Когда задача завершена, она перемещается в следующий столбец. Если архитектура неверна или неопределенна, она может быть перенесена обратно в предыдущий столбец.
- Тест : задача находится в этой колонке Канбан, пока она тестируется. Если есть какие-либо проблемы, он возвращается в «Разработка». Если их нет, то он перемещается в следующий столбец.
- Развертывание : каждый проект имеет свое собственное развертывание. Это может означать размещение новой версии на сервере или просто фиксацию кода в хранилище.
- Готово : карта появляется в этом разделе доски Канбан, когда предмет полностью закончен и больше не о чем беспокоиться.
Задачи с высоким приоритетом могут отображаться в любом столбце. Запланировано или нет, они должны быть выполнены немедленно. Для этих предметов на доске Канбан может быть даже создана специальная колонка. На нашем примере изображения он помечен как «Ускоренный». Одна из приоритетных задач может быть помещена в «Ускорение», чтобы команда начала и закончила как можно скорее, но только одна такая задача может существовать на доске Канбан! Если другой объект создан, его следует добавить в «Очередь историй» до тех пор, пока не будет решена существующая приоритетная задача.
Давайте поговорим об одном из самых важных элементов доски. Вы видите числа под каждым столбцом на доске с примерами? Это количество задач, которые можно разместить одновременно в каждом столбце. Цифры подбираются экспериментально, но обычно они основаны на количестве разработчиков в команде — способности команды к работе.
Если в команде восемь программистов, вы можете указать столбцу «Разработка» 4. Программисты могут работать одновременно только с четырьмя задачами в процессе разработки, и у них будет много причин для общения и обмена опытом. Если вы поставите 2, они могут начать скучать и тратить слишком много времени на обсуждения. Если вы дадите ему 8, то каждый программист будет работать над своей задачей, но некоторые элементы будут оставаться на доске слишком долго, в то время как основная цель методологии Канбана заключается в сокращении времени от начала задачи до ее завершения.
Никто не может дать вам точный ответ о пределах задачи — каждая команда отличается. Хорошее место для начала — это разделить число разработчиков на две части и адаптировать цифры на основе опыта.
Под «разработчиками» я имею в виду не только программистов, но и других специалистов. Например, специалисты по QA являются разработчиками для колонки «QA», так как ответственность за тестирование лежит на них.
Как команды извлекают выгоду из Kanban
Какие преимущества команда получит от методологии Канбан с этими ограничениями?
Во-первых, уменьшение количества задач, выполняемых одновременно, сократит время, необходимое для выполнения каждой из них. Нет необходимости переключать контексты между задачами и отслеживать различные объекты, поскольку выполняются только необходимые действия. Нет необходимости проводить планирование спринта и 5% семинаров, потому что планирование уже было выполнено в столбце «Очередь истории». Углубленная разработка задачи начинается только после ее запуска.
Во-вторых, шоу-стопперы видны сразу. Когда специалисты по обеспечению качества, например, не могут выполнить тестирование, они заполняют свой столбец, и программисты, готовые к новым задачам, не смогут переместить их в столбец «Тест». Что должно быть сделано тогда? В такой ситуации самое время вспомнить, что вы команда, и решить проблему. Программисты могут помочь выполнить одну из задач тестирования и только после этого переместить новый элемент в следующий столбец. Это поможет выполнить оба пункта быстрее.
В-третьих, время для выполнения средней задачи может быть рассчитано. Мы можем регистрировать даты, когда карта была добавлена в «Очередь историй», когда она была запущена и когда она была завершена. Мы можем рассчитать среднее время ожидания и среднее время до завершения по этим трем точкам. Менеджер или владелец продукта может рассчитать все, что он или она хочет, используя эти цифры.
Методология Канбан может быть описана только с тремя основными правилами:
- Визуализируйте производство:
- Разделите свою работу на задачи. Запишите каждый из них на карточку и положите карточки на стену или доску.
- Используйте указанные столбцы, чтобы показать положение выполняемой задачи.
- Ограничить WIP (работа в процессе или работа, выполненная одновременно) на каждом этапе производства.
- Измерьте время цикла (среднее время выполнения) и постоянно улучшайте процесс, чтобы сократить это время.
В методологии канбан только три основных правила!
Существует девять основных правил в методологии SCRUM, 13 в методологии XP и более 120 в классической методологии RUP. Почувствуйте разницу.