В чем разница между Scrum и Kanban?

Расспросили Дмитрия Курдюмова, Agile коуча, основателя агентства Smart Units, о различиях Scrum и Kanban.

Зачастую при построении процессов разработки возникает вопрос: "Что использовать — Scrum или Kanban? Что подойдет нашей команде?" Давайте разбираться, можно ли их вообще сравнивать.

Последние 10 лет информационные технологии повсеместно проникают в нашу жизнь. За счет них клиенты получают более быстрые и персонализированные сервисы с фокусом на конкретные потребности. С увеличением конкуренции растет скорость изменений и вместе с этим борьба за клиентов. У компаний появилась потребность в создании гибких процессов и системе, которая бы позволила максимально оперативно подстраиваться под изменяющийся рынок, при этом делая потребности пользователя основным фокусом.

Scrum — один из таких фреймворков. Он позволяет бизнесу итеративно создавать небольшие кусочки продукта и тестировать их на рынке, что дает ему возможность быстро собирать обратную связь и минимизировать риск выпуска ненужного продукта и функциональности. С его помощью компания создает лучшие продукты и быстрее приходит к своим бизнес целям, быстрее отказывается от ненужных решений и не тратит на них время.

Скрам задает жесткие ограничения в процессе и структуре, которые должны обязательно выполняться.

Фундаментальный элемент — Скрам-команда — самоуправляемая команда людей, которая самостоятельно определяет цель и вектор движения к ней. Конечно, цель не может быть в отрыве от главной бизнес-цели компании и стратегии.

Скрам мастер — отвечает за эффективное внедрение фреймворка Скрам в процессы.

Владелец продукта — отвечает за максимизацию ценности того, что создает Скрам-команда. То есть он анализирует рынок, приоритезирует потребности, определяет, что сейчас является наиболее важным для пользователей, как максимизировать бизнес-ценность для компании.

Команда разработки (в новой версии Скрам их назвали Разработчики) — это все компетенции, которые необходимо иметь внутри команды, чтобы создать продукт. Они отвечают за создание готового, качественного кусочка продукта в течение каждого спринта. В результате спринта не должно оставаться недоделанной работы.

Важно, что такие команды должны быть организованы непосредственно вокруг продукта. Продукт — это то, что решает задачу клиента и несет ценность компании. Подобные команды не стоит выстраивать вокруг компонент или функциональных отделов. Для этих целей Скрам не подойдет, так как фреймворк задумывался не для решения оперативных задач, а для того, чтобы достигать продуктовых и бизнесовых целей быстрее, сокращая риски.

Скрам — это не про “сделать больше задач и успеть в срок”. Здесь будет уместнее говорить про возможность создавать небольшими порциями продукт с целью получить обратную связь от пользователей, рынка, заинтересованных лиц, чтобы на основе новых знаний лучше понимать, куда двигаться дальше в процессе разработки. Скрам — это про работу в условиях неопределенности, когда результат плохо предсказуем.

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

Или, скажем, у вас уже есть работающий продукт и вам нужно улучшить конверсию (то есть количество переходов) из корзины в оплату. Ответ не очевиден. Чаще всего задача в лоб не решается, требуются эксперименты, поэтому процесс работы команды строится итерациями (в Скрам они называются Спринты).

В результате каждого спринта команда должна создать законченный кусочек продукта, который можно показать пользователям и другим стейкхолдерам, чтобы получить обратную связь. Команда заранее определяет критерии готовности продукта, чтобы одинаково понимать что нужно сделать, чтобы продукт считать готовым. Условия выбора задач в спринт не должны быть слишком детальные, наличие излишнего анализа и документации также не приветствуются. В Спринте не должно остаться незаконченной работы!

Несмотря на гибкость фреймворка, не стоит забывать о таком важном этапе, как планирование. Планирование спринта проводится для определения объема работы на спринт и целей спринта. Внутри спринта команда использует следующие ритуалы:

Работа команды и ее взаимодействие со стейкхолдерами должна быть прозрачной. Для этого используется достаточно распространенный инструмент — доска, на которой визуализируются все процессы и работы. Так как Scrum отвергает разделение ответственности и ярко выраженные этапы (например, они могут идти параллельно), количество колонок зачастую минимально, их три: to do — взяли на спринт, in progress — в процессе, done — имеем результат.

Kanban — это не подход, не фреймворк, а метод (или инструмент), который можно использовать для улучшения производственной эффективности. Он изначально базируется на принципах Lean, в основе которых лежит устранение потерь в работах. Например, в процессе разработки какие-то задачи могут простаивать, какие-то передаваться между отделами, какие-то быть явно лишними и не совсем актуальными или требовать ресурсов сразу нескольких команд. Kanban — метод, позволяющий визуализировать всю работу и имеющиеся процессы для их постепенного улучшения. Это может быть как на уровне персональных задач, уровне команды, так и на уровне стратегии компании.

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

Канбан-метод базируется на эволюционном развитии процесса, это его основной принцип, который позволяет создать предсказуемый и управляемый поток создания ценности. Условно говоря, — конвейер который функционирует без простоев, задержек и лишней работы.

Визуализировать работу и процесс.

Обычно это делается с помощью Канбан-доски, где изображаются все этапы, через которые проходит работа. Так, количество колонок может быть больше, чем в Scrum, например, колонки “очередь”, “выбрано”, “анализ”, “тестирование” и так далее. Другие рекомендации без визуального представления не будут иметь смысла — чтобы управлять работой, нужно видеть и понимать ее. Суть инструмента — визуализировать процессы нашей работы: как она движется, по каким правилам, какие задачи выполняются, какие застопорились, а по каким ожидается ответ от других департаментов.

Ограничить одновременно выполняемые работы.

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

Начать собираться вокруг доски и управлять потоком работы.

Например, можно проводить ежедневные встречи, на которых будет определяться план работы на день, будут рассматриваться “зависшие” задачи и оперативно приниматься решения по их урегулированию. Также, важно смотреть на метрики потока и строить гипотезы об их улучшении. Цель — создать плавный процесс прохождения работы через систему, минимизируя препятствия и потери.

Внедрить понятные правила работы.

Для каждого члена команды работа с канбан должна быть прозрачной. Крайне важно убедиться в том, что все понимают “правила игры”. Чтобы избежать недопонимания, необходимо эти правила зафиксировать и визуализировать для общей вовлеченности: например, какие критерии готовности каждого этапа системы, какие задачи являются приоритетными, как определить необходимость пополнения бэклога идей и так далее.

Совершенствовать процессы.

Канбан-метод — это не просто инструмент управления работами. Это метод эволюционных улучшений: с помощью визуализации метрик мы можем отследить несовершенства процессов и на их основе модернизировать функционирование команды. Главная цель канбан-метода — постоянные улучшения на основе метрик и экспериментов.

Если вы заняты в сфере разработки и создаете продукт, оптимальным решением для вас будет использовать фреймворк Scrum, усиленный Kanban-методом. Например:

Также, важный момент — не всегда уместно сравнивать Scrum и Kanban, так как Скрам — это фреймворк, а Канбан — это инструмент. Они вполне могут использоваться вместе, дополняя друг друга.

Телеграмм-канал Дмитрия: https://t.me/agilegurukitchen

Больше узнать об управлении командой и проектами можно на курсе “Project manager” с гарантированным трудоустройством и обучением на реальных кейсах.

А если определиться с направлением профессии сложно, приходите на бесплатную карьерную консультацию с топовым экспертом сферы IT.

#scrum #kanban #agile #управлениепроектами