В прошлый раз мы говорили о scrum, сегодня поговорим о kanban. Это тоже методология разработки, тоже инструмент управления проектами и он тоже относится к Agile. Kanban основан на использовании специальных досок, вообще их еще называют бордами. На доске отражены все задачи, которые есть у команды и вообще на которых ведется работа. Эти задачи разбиты на этапы и каждому этапу соответствует колонка на доске. Вот пример самый простой Канбан доски: есть три колонки новая задача, задача в работе, выполненная задача.
И в каждой колонке есть какие-то карточки их называют карточками или задачами. По мере того как задачи берут в работу, они проходят через все этапы и так можно визуализировать весь рабочий процесс. Весь Канбан построен именно на визуализации процесса выполнения задач команды.
Как работает kanban?
Для того чтобы начать работать по канбану с вашей существующей командой или может быть с новой командой, для начала конечно нужно определиться с этапами которым вы следуете для выполнения задач. Это может быть дизайн, разработка кода, тестирование и сдача, или может быть какой-нибудь другие вещи. Поэтому нужно для начала выписать какие этапы. В принципе не обязательно делать это очень точно. Вы может начать даже с самой простой задачи и постепенно улучшать ваш процесс. После того как вы выписали этапы работы, вы можете создать доску и на доске отразить это в виде колонок. Доски можно создавать как на настоящих досках, например как на картинке выше или можно создавать например в инструменте вроде Jira, track, trello. Сейчас есть много популярных инструментов. По мере того как вы создаете доску, часто полезно для каждой колонки выставить ограничение: какое-то ограничение по количеству активных задач. Таким образом можно выявить если какая-то колонка накапливает слишком много задач, то у вас в этом месте есть какое-то замедление, узкое место в процессе.
После того как вы создали доску то можно добавлять в неё задачи, и пытаться проводить задачи по этому процессу. То есть работники передвигают задачи с колонки в колонку, вы как менеджера можете видеть какие задачи в работе и когда они будут выполнены и какие уже выполнены. И вот в этот момент, ключевая философия kanban начинает работать. Вы можете выявлять недостатки и предлагать улучшения процесса и пытаться их вводить. Например, добавлять новые колонки, изменять формулировку задач, или если вы понимаете, что у вас всё время слишком много задач в разделе дизайна, можно просто нанять новых дизайнеров и расширить команду. Вот на этом построен весь канбан.
Ключевые отличия Kanban от Scrum
Поскольку и то и другое относится к семейству Agile. То и там и там примерно одинаковый роли: есть заказчик, есть менеджер, есть однородная небольшая команда. И там и там есть backlog, в котором есть какие-то user story, которые просто описывал требования. Но самое главное отличие в том что Scrum подходит, когда нужен четкий график выполнения задачи, работы. В srcum есть спринты и к концу каждого спринта, команда сдает какую-то работу. В kanbam задачи оценивается по времени и сдаются индивидуально. Это значит, что по мере того как сдача взята в работу, конкретная задача оценивается, конкретно независимо от других, проходит по всем этапам, так как удобно вашей команде. И как только задача выполнена её можно сдать на Production или отдать/ показать заказчику. Нет четкого графика. То есть Канбан в целом более гибкий и фокусирован на отладке конкретно вашего рабочего процесса, а не удовлетворения четких требований и планов.
Не создается ли некий хаос в процессе работы?
Может появиться хаос, если есть какая-то работа в команде или на проекте, которая не отражается на доске, вот этого очень важно избегать. Если какая-то работа или какая-то часть вашего процесса не отражена на доске, и ее нельзя увидеть, то это создает хаос, потому, что теряется контроль. А если доска организована хорошо и люди придерживаются использования доски, то как раз благодаря визуализации можно хаоса избежать и организовать процесс лучше.
Например srum абсолютно не применим в таких командах как тех поддержка, потому что, по мере того как задачи поступают, вы их решаете, нет никакого плана, нет спринта, непредсказуемость. Но с другой стороны можно четко описать шаги работы техподдержки: поступаю какие-то запросы клиентов, вы и их анализируете, и можете передать в разработку, потом отдать обновление заказчику и так далее. Это можно представить в виде Канбан доски и очень удобно выявлять например, что на каком то конкретном этапе вы очень медленно решайте вопрос заказчиков или есть какая-то зависимость которая мешает.
Другим хорошим примером использования канбан, является подбор сотрудников. Часто HR применяют вот такую доску.
В этой доске есть несколько этапов. Например у вас есть новые кандидаты, есть кандидаты на этапе рассмотрения резюме, есть кандидаты на этапе собеседования. После собеседования вы можете принимать решения, и потом этого кандидата вы либо берете на работу, либо оказываете. И весь процесс можно написать в виде Канбан доски. Каждая задача или каждая карточка на доске — это новый кандидат на работу. На этой доске видно, что есть ограничение на количество людей, которых вы будете рассматривать, потому что очень неудобно было бы провести 10-15 собеседование и потом пытаться выбрать лучшего кандидата, гораздо удобнее провести несколько например два или три и выбрать между 2 или 3. Поэтому колонка показывается красным, потому что здесь слишком много людей в рассмотрении. Это неэффективно, можно определить что тормозит процесс. Например, если технический специалист слишком долго рассматривает резюме и это тормозит весь процесс, то можно подключить больше технических специалистов или изменить процесс рассмотрения. К тому же благодаря тому, что в целом все карточки и рассмотрение кандидатов однотипное, то можно выявить статистику, как много карточек проходит через все эти этапы например в месяц или в неделю. Так можно понять как много людей вы можете эффективно рассмотреть за какой то промежуток.
Канбан в процессе разработки продукта
По сколько это методология аджайл то она в первую очередь предназначена для разработки обычными командами.
Более продвинутый пример, когда используется ни одна канбан доска, а сразу две. Потому что зачастую когда задачи берутся из бэклога прежде чем взять их в работу нужно может быть добавить им больше детализации, более подробно описать требования и например нарисовать дизайн, потому что по дизайнам гораздо удобнее оценивать задачи. И поэтому есть две доски, одна доска включая такие шаги как сам бэклог, задача взята в работу и находится на этапе расписания product manager. После того как продукт менеджер полностью расписал задачу её можно передать дизайнерам, и дизайнеры будут делать какие-то макеты или шаблоны. После того как дизайнеры закончили свою работу и можно передать в разработку, то она висит на верхней доске, пока у программистов не появляется время и они могу взять новую задачу. Как только программисты могут взять следующую задачу, они берут уже готовую дизайненую задачу и по дизайну делают оценку. После того как закончена оценка, задача берется в работу и программисты пишут код. После того как код написан, переходим на этап тестирования, тестировщики работают. После того как например был найден баг, задачу можно вернуть назад в разработку. Как только задача проходит этап тестирование она попадает в деплоймент, затем на сервер, и все задача выполнена. Таким образом у нас есть две независимые доски которые соответствуют своей команде, например команде разработки дизайна и команде разработки продукта, реализации. Можно выявлять на каком этапе у вас не хватает силы, на каком этапе задачи стопорятся. Поэтому на каждой из колонок, можно добавить какое-то максимальное количество активных зада. Вот так с помощью Канбан можно очень удобно организовать рабочий процесс.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.