Какая методика подойдет вам: Kanban или Scrum
Когда для работы команды больше подойдет Kanban-методология, а когда Scrum? Разбираемся в статье на примерах.
Kanban и Scrum – две самые популярные agile-методологии. Согласно исследованию ScrumTrek, 73% участников отмечают, что с внедрением Agile в команде, разработка и выпуск продукта на рынок ускорились.
Обе методологии направлены на улучшение работы над проектами и повышение качества продукта. Однако сами подходы к работе и принципы реализации в них разные. Что хорошо для одной команды, не значит, что будет также полезно для другой.
В этой статье мы рассмотрим ключевые различия между Kanban и Scrum, чтобы помочь вам выбрать методологию для проекта.
Что такое Scrum: структура, спринты, бэклог
Это методология, которая чаще всего используется для управления разработкой программного обеспечения. В России Scrum используют 82% специалистов различных сфер: ИТ, телеком, энергетика, промышленность и торговля.
Методология предполагает итеративный подход к реализации проекта, где вся активность разбита на короткие циклы (спринты), обычно длительностью от 1 до 4-ех недель.
Основные компоненты:
- Спринт – основная единица разработки, ограниченная по времени (1–4 недели);
- Дейли – ежедневные короткие встречи команды для обсуждения прогресса;
- Скрам-мастер – человек, который отвечает за соблюдение принципов Scrum и помогает команде их реализовывать;
- Продуктовый владелец (Product Owner) – человек, который отвечает за определение требований к продукту и приоритизацию задач для команды;
- Бэклог продукта – список всех тасков, которые нужно выполнить.
Что такое Kanban: доска, поток, гибкость
Это более гибкая и менее структурированная методология. Она была разработана в компании Toyota для оптимизации производства и управления запасами.
Основная идея Kanban – визуализация рабочих действий, что позволяет улучшить поток работы над проектами и повысить эффективность команды.
Маргарита Соколенко
Основные элементы Kanban:
- Доска – визуальное представление рабочего процесса, разделенное на колонки (например, «В очереди», «В работе», «Готово»);
- Карточки. Каждая задача представлена карточкой, которая заполняется необходимыми данными (исполнители, сроки, приоритеты и т. д.) и перемещается по колонкам доски по мере выполнения.
- Ограничение количества тасков в работе (WIP-лимиты). Помогает предотвратить перегрузку команды;
- Постоянный поток. Фокусируется на непрерывности процессов, в отличие от итеративного подхода.
В чем Scrum и Kanban похожи
Гибкость и адаптивность
- Отзывчивость к изменениям. Методологии поощряют команды к быстрой адаптации к изменяющимся требованиям в работе над проектами и условиям рынка.
- Непрерывное улучшение. Обе методологии фокусируются на постоянном улучшении действий и продукта, что отражено в знаменитом Agile-манифесте.
Повышение прозрачности и визуализация работы
Используют визуальные инструменты для отслеживания прогресса работы команды, такие как Kanban-доски и Scrum-доски. В Scrum это может быть доска спринта, которая показывает таски на разных стадиях выполнения, и дополнительной колонкой «Бэклог».
Непрерывное улучшение
Методологии включают регулярные сессии ретроспективы, на которых команда обсуждает, что работало хорошо и что можно улучшить.
В Scrum ретроспективы команды проводятся в конце каждого спринта, в то время как в Kanban они могут быть менее формализованы и проводиться по необходимости.
Отличия подходов
1. Итерации vs Непрерывный поток
Scrum подразумевает четкую временную структуру – спринты. Каждый спринт начинается с планирования и заканчивается демонстрацией продукта и ретроспективой.
В течение спринта бэклог задач обычно остается неизменным, что помогает команде сосредоточиться на установленных целях.
В Kanban нет фиксированных итераций. Таски могут добавляться и изменяться в любое время, обеспечивая большую гибкость и способность команды адаптироваться к изменениям.
Ключевой элемент, который помогает предотвратить перегрузку команды и поддерживает непрерывный поток работы при Kanban – WIP-лимиты.
2. Роли и ответственности
Scrum про четкие роли. Скрам-мастер поддерживает команду и процесс, а Product Owner управляет бэклогом и приоритетами. Команды мультидисциплинарны и самоорганизуются, то есть не требуют микроменеджмента и строгого руководства.
В Kanban не определены строгие роли команды. Упор делается на оптимизацию рабочего процесса и управление потоком задач.
3. Планирование и изменения
При Scrum-подходе в начале каждого спринта команда определяет объем работы, который она сможет выполнить. Таски, выбранные для спринта, остаются неизменными до его окончания.
В Kanban карточки с заданиями могут добавляться, изменяться или удаляться в любое время.
Когда больше подходит Kanban
1. Проекты с высокой динамикой изменений
В управлении проектами Kanban идеален для сред, где вводные данные и приоритеты часто меняются. Это может быть связано с быстро меняющимися требованиями клиентов или рынка. Например, в компаниях, которые работают в области digital-маркетинга, где тренды меняются постоянно.
2. Непрерывная работа и поддержка
Подходит для направлений деятельности, где дела нужно выполнять непрерывно: в поддержке, обслуживании и т. д. Например, в отделе технической поддержки интернет-провайдера, где команды постоянно консультируют пользователей и решают проблем.
3. Разнообразие задач и специализаций
Если команды в проекте выполняют различные типы задач, Kanban позволяет эффективно управлять этим разнообразием. Например, если вы – производственная компания, где есть как краткосрочные, так и долгосрочные задачи с разными уровнями сложности.
4. Команды, нуждающиеся в гибкости
Методология хорошо подходит для команд, которым важна гибкость в планировании и выполнении работ, без строгих временных рамок. Например, для дизайн-студий, работающих над несколькими проектами одновременно, где требуется постоянная адаптация к новым идеям и требованиям.
5. Проекты с неопределенными сроками или объемами работы
По Канбан можно управлять тасками, даже если у проекта неопределенные дедлайны и объемы работ. Например, в исследовательских лабораториях, где управление проектами меняется в зависимости от результатов экспериментов и тестов.
Когда больше подходит Scrum
1. Проекты с четко определенными фазами и сроками
Подходит для управлениями такими проектами, в которых работа должна быть организована в строго определенные итерации (спринты) с конкретными сроками и результатами. Идеально для команды разработки программного обеспечения, где каждый спринт включает определенный набор функций для реализации.
2. Комплексные проекты с множеством междисциплинарных задач
Scrum подходит в управлении проектами, в которых нужно согласовать работу людей с разными специализациями. Например, при разработке нового Жилого комплекса, где участвуют инженеры, дизайнеры, маркетологи и аналитики.
3. Проекты, в которых необходимо быть на связи с клиентом
Сама концепция ретроспектив, в которых команда анализирует проделанную работу, подразумевает отчетность и обратную связь. Например, если та же разработка программного продукта требует регулярно показывать прогресс заказчику и адаптироваться к его требованиям.
4. Проекты, в которых нужно пересматривать приоритеты
Приоритеты и таски пересматриваются в начале каждого спринта. Это применимо при разработке IT-системы, где требования могут изменяться в процессе реализации проекта, исходя из фидбека тестовых групп.
5. Проекты, в которых нужно четко разделять функции и ответственность
Как мы уже отмечали, в Scrum четкие роли, вроде Скрам-мастера и Владельца продукта, команды исполнителей. Это актуально, если, вы, например, ведете большой проект по разработке ПО, скажем, для госструктур, где важна строгая организационная структура.
Пример организации рабочего процесса по методологии Scrum
Лучше всего рассмотреть различия этих методологий можно на примерах. Представим, что ваша команда разрабатывает мобильное приложение для учета финансов. Рабочий процесс строится так:
1. Создание бэклога продукта (Product Backlog)
Продукт: Новое мобильное приложение.
Продуктовый владелец (Product Owner) определяет список функций, необходимых для приложения, и упорядочивает их по приоритету. Это могут быть функции вроде пользовательского интерфейса, системы авторизации, интеграции с социальными сетями и т.д.
2. Планирование спринта (Sprint Planning)
Команда разработчиков выбирает, какие функции из бэклога они могут реализовать в следующем спринте. Создаются таски и оценивается время на их выполнение.
3. Спринт (Sprint)
В течение спринта команда работает над выбранными задачами. А на ежедневных коротких встречах (Daily) команда обсуждает прогресс и проблемы.
4. Проверка и адаптация (Review & Retrospective)
Спринт Ревью: По окончании спринта команда показывает заказчику, что было сделано, получает обратную связь от продуктового владельца и заинтересованных сторон.
Ретроспектива Спринта: Команда обсуждает, что работало хорошо, что можно улучшить, и планирует изменения на следующий спринт.
5. Следующий спринт
Начинается новый цикл с планирования спринта, где выбираются новые или оставшиеся задачи из бэклога. Этот цикл повторяется до тех пор, пока продукт не будет завершен или пока продолжается его развитие.
Пример организации рабочего процесса по Канбан
Теперь рассмотрим, как организовать работу по Kanban-методологии. Например, ваша команда занимается разработкой и поддержкой корпоративной CRM-системы. Процесс работы можно представить так:
1. Визуализация рабочего процесса
Создается доска (физическая или цифровая), которая отражает ключевые этапы рабочего процесса: например, «Запланировано» (To Do), «В работе» (In Progress), «Тестирование» и «Завершено».
Задачи (например, исправление ошибок, добавление новых функций) добавляются в колонку «Запланировано.
2. Ограничение количества работы (WIP)
Устанавливается максимальное количество задач, которое может быть в работе одновременно. Например, можно допустить только 3 таска одновременно в разработке и 2 в тестировании. Это снижает нагрузку команды и повышает качество работы.
3. Управление потоком
Как только карточка перемещается из одной колонки в другую, команда может добавлять новые карточки, соблюдая установленные ограничения WIP. Так получается непрерывный поток работы, где вы можете менять приоритеты в зависимости от разных вводных данных.
4. Регулярные встречи
Команда регулярно проводит короткие встречи у доски, чтобы обсудить: что получилось, а что нет, кто сколько времени провел в работе над задачей, как можно это оптимизировать. Данные для анализа за вас соберет таск-менеджер. Например, в Shtab для этого есть сводные отчеты и отчеты активности по команде.
5. Непрерывное улучшение
После выполнения работ команды анализируют процесс и ищут способы, как повысить эффективность. Этот метод подходит для команд, в которых нужно почти мгновенно реагировать на новые таски, запросы клиентов и изменения в продукте.
Выводы
В управлении проектами выбор между методологиями зависит от характеристик проекта и требований к рабочему процессу. Обе методологии имеют свои преимущества.
Kanban лучше всего подходит для проектов, где требуется высокая гибкость, способность к быстрой адаптации к изменениям и непрерывный поток работы. Это идеальный выбор для динамичных проектов с часто меняющимися приоритетами, а также для работы, где важно управление запросами, например, для команды техподдержки.
Scrum, с другой стороны, предпочтительнее для структурированных проектов с четкими итерациями и определенными сроками. Он идеален для комплексных проектов, в которых нужно постоянно и тесно взаимодействовать с клиентом, организовывать работу мультидисциплинарной команды.
Визуализировать работу удобно в сервисе Shtab, где команды могут отслеживать, на каком этапе находятся задачи, а также сколько времени они занимают.
