Kanban или Scrum: в чем отличие и как работает? Наш опыт

Какой подход лучше для разработки — Kanban или Scrum? Вопрос стар как мир. Обе концепции предлагают вполне логичные принципы организации работы и управления проектами. Мы решили поделиться своим опытом и рассказать, что ближе нам. Но для начала немного теории. 

Что общего и разного у Kanban и Scrum

Концепции управления проектами Kanban и Scrum выросли из Agile-манифеста. Это документ, опубликованный в 2001 году группой из 17 разработчиков. В нем сформулированы принципы и ценности Agile-подхода, основанные на гибкости, коллаборации и быстрой адаптации к изменениям. Манифест стал фундаментом для различных гибких методологий, среди которых большую популярность завоевали Kanban и Scrum.

Методология управления проектами Kanban строится на визуализации рабочего процесса и управлении потоком работы. Ее основной принцип — в ограничении количества задач, находящихся в работе одновременно. Работа по Kanban предполагает постоянное улучшение процессов и активное участие всех членов команды в управлении проектом.

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

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

Методология Kanban 

Базовые принципы Kanban, которые помогают управлять потоком задач и повышают эффективность процесса разработки:

1. Визуализация процесса работы. Все задачи и этапы реализации проекта отображаются на доске. Все члены команды видят, какие задачи выполняются, какие ждут очереди, а какие — завершены.

2. Ограничение количества задач. Для каждого этапа работ устанавливаются лимиты, чтобы не допускать перегрузок и отложенных результатов.

3. Управление потоком. Команда стремится к равномерному потоку задач. Работу координирует проектный менеджер.

Есть множество приложений для работы с Kanban-досками: Jira, Trello, YouGile, Asana и другие. Фактически все это цифровые версии аналогового прототипа — обычной доски со стикерами.

Каждая задача представляется на доске в виде карточки. Карточка содержит информацию о задаче, ее статусе и приоритете. Все карточки разносятся по колонкам, каждая из которых соответствует статусу задачи. Например, To Do, In Progress и Done. Для каждой колонки устанавливаются WIP-лимиты (Work in Progress) на количество задач, которые могут находиться в ней одновременно.

Что круто в Kanban

Приверженцы методологии Kanban в числе ее преимуществ называют:

• Прозрачность. Визуализация на доске предполагает видимость задач и статусов всем участникам команды. Это упрощает взаимодействие и повышает эффективность работы. 

• Гибкость. Kanban позволяет команде быстро реагировать на изменения и при необходимости вносить коррективы в работу. Например, повышать приоритет задач в In Progress или возвращать в To Do.

• Эффективность. Ограничение количества задач в работе и управление потоком позволяют улучшать производительность и экономить время.

• Коммуникации. Kanban стимулирует команду общаться, делая процессы более прозрачными и понятными для всех участников.

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

Что не так с Kanban 

Дадим слово критикам Kanban и перечислим слабые места методологии:

• Ограничения в применении. Kanban может быть неэффективным, когда дело касается разработки сложных продуктов, требующих более строгого планирования и контроля над ресурсами.

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

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

• Микроконтроль. Kanban требует постоянного обновления доски и контроля мелких процессов, что может отнимать лишнее времени у менеджера и команды.

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

Кому подходит Kanban 

Проектные команды могут придерживаться методологии Kanban на этапе разработки MVP, когда уровень неопределенности высокий, а цена ошибок или срыва дедлайна, наоборот, не так высока. Для продуктов со сложной иерархией, требующих работы большой группы специалистов, компромиссом может быть разделение на небольшие Agile-команды и проекты.

Читайте также: «Что такое MVP в IT?»

Фреймворк Scrum

Если Kanban представляется харизматичной личностью с умеренной долей творчества в работе, то Scrum — белый воротничок, у которого все по порядку и протоколу. Он опирается на свои принципы:

1. Итеративность. Работа разбивается на короткие спринты, финалом каждого спринта должен быть готовый к выпуску продукт или пакет фич к уже существующему продукту.

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

3. Прозрачность. Весь процесс работы команды и состояние продукта обсуждается, вся информация доступна всем участникам проекта.

4. Совершенствование. Команда постоянно анализирует процессы, чтобы найти способы оптимизировать затраты и повысить эффективность работы.

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

Scrum жестко привязывается к срокам и событиям. Весь поток разделяется на спринты — короткие периоды времени (обычно 2-4 недели), в течение которых команда работает над определенным набором задач. Ежедневно проводятся стендапы — совещания команды, на которых каждый участник отвечает на три вопроса: что было сделано, что планируется сделать, есть ли проблемы или препятствия. По завершении спринта проводятся ретроспективы — встречи для обсуждения проделанной работы и способов усовершенствования продукта.

Что круто в Scrum

Несмотря на сложную схему работы и иерархию ролей, у Scrum есть свои преимущества:

• Адаптивность. Итеративный подход в основе фреймворка дает возможность быстро реагировать на изменения рыночных условий и требований к продукту.

• Скорости разработки. Благодаря коротким итерациям и самоорганизации команды процесс разработки может быть более эффективным.

• Улучшение качества продукта. Регулярные ретроспективы стимулируют к поиску лучших вариантов реализации и расширения функциональности продукта.

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

Что не так со Scrum

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

• Сложность внедрения. Переход на Scrum требует изменений в культуре компании и процессах работы, и далеко не всегда работники бывают этому рады.

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

• Снижение продуктивности. Ежедневные встречи и ретроспективы зачастую проводятся формально и для протокола, просто потому что так положено. Это отнимает время и демотивирует разработчиков. 

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

• Снижение качества продукта. Из-за необходимости постоянного внедрения фич через короткие итерации некоторые команды могут не уделять должного внимания качеству продукта. Это может привести к техническому долгу и другим проблемам.

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

Кому подходит Scrum

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

Читайте также: «Как найти владельца продукта внутри компании».

Scrumban — лучшее из двух миров

И вот мы подошли к самому интересному: за какой из двух подходов голосуем мы? Если в теории и без оговорок, то за Scrum. Но, как вы уже могли догадаться, мы идем по пути интеграции двух методологий. И мы не одиноки — многие западные и некоторые российские IT-компании тоже пришли к этому. Появился термин Scrumban для обозначения гибридного подхода, который объединяет в себе элементы Kanban и Scrum.

Scrumban сохраняет основные принципы Scrum, такие как итеративное развитие и регулярные ревью, и присваивает гибкость и визуальное управление задачами из Kanban.

Чтобы успешно комбинировать элементы Kanban и Scrum, нужно протестировать обе методологии и определить, какие элементы встраиваются в рабочие процессе. Например, в некоторых наших проектах Scrum-артефакты, такие как Product Backlog и Sprint Backlog, отлично «уживаются» с Kanban-доской. У нас нет практики ежедневных стендапов, но есть ретроспективы и сборы по необходимости. Нет Scrum-мастеров — их задачи и роль владельца продукта забирает на себя проектный менеджер. В одних проектах мы работаем четырехнедельными спринтами, в других — более продолжительными итерациями. Подход во многом зависит от специфики проекта и выбранной модели контракта.

В заключение

Чтобы выбрать подходящую методологию, важно учитывать специфику проекта, потребности команды и ее опыт работы с Agile-методологиями. Если команда работает над проектом с четко определенными требованиями и жесткими сроками, то Scrum может быть более подходящим выбором. Если проект меняется часто и требует гибкости в управлении задачами, вероятно, более эффективным вариантом будет Kanban или Scrumban.