Что такое Канбан
Большинство людей, отвечая на этот вопрос, говорят, что это — методология разработки. Но так ли это на самом деле? Я бы хотел помочь разобраться с этим вопросом.
Идея единого потока
Для начала нужно понять, что это вообще такое и для каких целей появилось. Канбан был изобретён проектными менеджерами на заводах Toyota для того, что бы процесс создания продукта (в данном случае, автомобилей) стал более прозрачным. Классическая схема, используемая в то время, предполагала производство огромного количества деталей в разных цехах или даже предприятиях, не связанных между собой. Перед финальной сборкой могли пройти дни, недели и даже месяцы. Таким образом, если один из отделов допускал ошибку, о ней узнавали только через несколько недель, и все это время выпускались бракованные комплектующие. Убытки в данном случае чудовищны: оплаченная работа, испорченный материал, транспортировка, складирование, переработка и время. Спасительной и ключевой здесь являлась идея создания единого потока.
Поток — это такой производственный процесс, где нет простоя незавершенных задач. Нет пауз, одно движение вперёд. Получается настоящая эстафета: задача, как та самая палочка, передаётся отделами четко из рук в руки. В этом случае ошибки предыдущей стадии очевидны и обнаруживают себя мгновенно. Это позволяет избежать бессмысленных трат, увеличивает качество продукта, снижает стоимость и уменьшает сроки выполнения.
Что же нужно сделать, дабы обеспечить возможность существования такого потока? Прежде всего, следует заменить классическую модель выталкивания на модель вытягивания. Что это значит? То, что каждый следующий этап производства готов принять результаты предыдущего этапа, и, следовательно, равен по своей пропускной способности или превышает его.
Как это выглядит на практике
Рассмотрим пример использования Канбана. Допустим, перед нами рядовая IT-компания, которая при производстве применяет итеративную методологию, а для отслеживания оперативной ситуации внутри спринта используется Канбан доска.
To do — спринт бэклог.
In progress — задачи, которые разрабатываются в данный момент.
Ready for deploy — задачи, которые уже выполнены, но не представлены в тестовом окружении.
QA — задачи, готовые к тестированию.
PO/PM approving — готовые задачи проходят проверку project owner-ом или проектным менеджером.
Done — выполненные (завершённые) задачи текущего спринта.
Процессы в спринте здесь проходят таким образом: приступая, разработчик перетягивает задачу из To do в In progress. В один момент времени он имеет только одну задачу, так как параллельное выполнение задач ничем хорошим не кончается. После окончания своей части работы, он перетаскивает её в колонку Ready for deploy.
Начиная с этого момента за дело берётся отдел тестирования. По достижению лимита задач в этой колонке QA инженер инициируют сборку билда, или сервера, или ещё чего-нибудь. В идеале для этих целей хорошо иметь continuous integration инструмент, такой как Jenkins, например. Также допустимо просто попросить разработчика собрать билд или обновить сервер. При успешных результатах тестирования задача отправляется в колонку PO/PM approving, где получает финальное подтверждение и перетягивается в последнюю колонку Done. Если задача не проходит тестирование, она снова попадает в колонку To do с соответствующим комментарием. Багрепорт имеет точно такой же жизненный цикл.
Для построения такого процесса необходимо, чтобы у всех членов команды были правильно настроены нотификации. В таком случае можно избежать простоя при переходе задач между исполнителями.
Также желательно осуществлять промежуточные поставки кода в колонку Ready for deploy, так как это сможет обеспечить более оперативную обратную связь. Скопление тасок в любой из колонок называется «бутылочное горлышко». Это значит, что пропускной способности на данном участке не достаточно, и нужно найти причину и решить её.
Для быстрой обратной связи QA инженер должен иметь возможность протестировать отдельные компоненты: БД, API, front-end, back-end.
Почему именно Канбан
С таким инструментом компания имеет слаженную работу, где каждый знает свою локацию на общей карте. Перед ней открываются все преимущества Канбана, из которых следует отметить:
— Уменьшение времени прохождения каждой конкретной таски и, как следствие, выполнения всего проекта в целом;
— Быстрая обратная связь от отдела тестирования;
— Раннее вовлечение тестировщиков и, как следствие, никакой головной боли перед релизом;
— Высокое вовлечение команды в процесс разработки;
— Выполнение проекта в срок за счёт уменьшения времени простоев и автоматизации интеграции;
— Высокое качество продукта.
Не верно называть Канбан методологией, так как мы не берем проект с нуля и не ведем до конца, к тому же тут не слова о документации или митингах. Канбан — это инструмент, который помогает сгладить неровности и явно показывает, в каком месте стоит улучшить текущие процессы. Пользуйте Канбан с умом.
