Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban. В этой статье разберём основные различия между ними, чтобы помочь вам выбрать наиболее подходящую методологию для вашего проекта.
Agile: Основные принципы
Прежде чем углубляться в различия между Scrum и Kanban, напомним, что объединяет эти методологии. Agile-манифест, сформулированный более 17 лет назад лидерами IT-разработки, выделяет следующие ключевые идеи:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Эти принципы подчеркивают гибкость, ориентацию на результат и постоянное взаимодействие с пользователями и заказчиками.
Scrum: Основные особенности
Scrum – это методология, которая основана на коротких итерациях или спринтах, обычно продолжительностью 2-3 недели. Основные характеристики Scrum:
- Итерации и спринты: Работа делится на короткие, фиксированные временные промежутки (спринты). В конце каждого спринта команда оценивает проделанную работу и планирует следующий.
- Роли: В Scrum есть определённые роли – Product Owner, Scrum Master и команда разработчиков. Каждый из них выполняет свою функцию.
- Ежедневные встречи: Daily Stand-up – короткие ежедневные встречи, на которых команда обсуждает прогресс, препятствия и планы на день.
- Оценка задач: Задачи оцениваются в Story Points или часах. Это помогает планировать и прогнозировать работу.
- Velocity: Производительность команды измеряется в Story Points за спринт. Это позволяет прогнозировать объём работы на будущее.
Kanban: Основные особенности
Kanban – методология, которая возникла в производстве, но прекрасно адаптирована для разработки ПО. Основные характеристики Kanban:
- Непрерывный поток задач: В Kanban нет фиксированных итераций. Задачи выполняются по мере поступления и готовности.
- Визуализация работы: Используется доска Kanban, на которой отображаются все этапы работы (например, To Do, In Progress, Done).
- Лимиты WIP (Work In Progress): Ограничение на количество задач, выполняемых одновременно. Это помогает избежать перегрузки команды.
- Cycle Time: Время, затраченное на выполнение одной задачи, отслеживается и оптимизируется.
- Гибкость: Приоритеты задач можно менять в любой момент, что позволяет быстро реагировать на изменения.
Scrum vs Kanban: Основные различия
Итерации и временные рамки
- Scrum: Работа организована в спринты продолжительностью 2-3 недели. В конце каждого спринта команда оценивает результаты и планирует следующий.
- Kanban: Нет фиксированных итераций. Работа выполняется по мере поступления задач и готовности команды.
Роли и структуры
- Scrum: Четко определены роли (Product Owner, Scrum Master, команда разработчиков) и процессы (ежедневные встречи, ретроспективы, планирование спринтов).
- Kanban: Нет строгих ролей и структур. Команда сама решает, как организовать свою работу.
Оценка задач и производительность
- Scrum: Задачи оцениваются в Story Points или часах. Производительность команды измеряется через Velocity.
- Kanban: Оценка задач опциональна. Основной показатель – Cycle Time, который показывает, сколько времени уходит на выполнение задачи.
Гибкость и приоритеты
- Scrum: Задачи в спринте фиксированы и не меняются до его завершения. Это обеспечивает стабильность, но снижает гибкость.
- Kanban: Приоритеты задач можно менять в любой момент, что позволяет быстро реагировать на изменения.
Как выбрать подходящую методологию?
Выбор между Scrum и Kanban зависит от специфики вашего проекта и команды:
- Scrum подойдет для проектов с четко определенными требованиями и временными рамками, где важна стабильность и предсказуемость работы.
- Kanban лучше использовать, если проект требует высокой гибкости и способности быстро адаптироваться к изменениям.
Обе методологии можно комбинировать в зависимости от потребностей проекта. Например, использовать Scrum для долгосрочного планирования и Kanban для гибкого управления ежедневными задачами.
Дополнительные элементы Kanban
Ограничение на количество задач (WIP)
Во-первых, это WIP (Work in Progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем их от выгорания: они делают только одну задачу в единицу времени.
А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника.
Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач – наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это всё издержки, которые понижали наш КПД. Тогда мы подключили на проект еще одного QA и проблема была решена.
Swimlanes
Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает – в рабочее время. Вы делегируете задачу вашему лиду или DevOps – «поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует её закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.
В данном случае у нас есть Swimlane под названием Blockers. Все задачи, которые требуют решения в режиме реального времени, ставятся в этом блоке. Программисты немедленно прекращают свою текущую задачу, ставят её на паузу и начинают делать блокер.
Также у нас есть очень полезный Swimlane под названием Someday. Туда мы сублимируем задачи, которые «да-да, обязательно сделаем когда-нибудь». Это реально помогает убрать все лишнее с глаз, чтобы люди могли сконцентрироваться на главном. А эти задачи, как правило, остаются там навсегда.
«Правильные» тестировщики находят много «правильных» багов, и это всё попадает в очередь программистам. Если эти баги не проверять и оставлять в основной очереди задач, то скоро вы обнаружите, что программисты заняты какой-то неважной ерундой. Поэтому в команде обязательно должен быть человек, а лучше несколько, которые понимают, какие баги критичны, а какие должны отправиться в неопределённое будущее, в Someday.
Под-колонки (Sub-columns)
У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он её переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенёс задачу на тест, у QA нарушен этот лимит. Стало две задачи.
Допустим, программист не будет переносить задачу на Тестирование и оставит её в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In Progress и Done. И когда программист заканчивает задачу, он переносит её в Done. Когда тестировщик освободится, он возьмёт новую задачу из под-колонки Done колонки Программирование и перенесёт её в свою колонку Тестирование.
Заключение
Подводя итоги, хочу отметить, что Scrum – гибкая методика разработки, а Kanban – ещё более. Всему своё время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning Poker. Scrum помогает детально погрузить команду в суть продукта.
А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на неё реагировать. Вы начинаете работать над HADI циклами – вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Всё увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.
А на чём вы остановили свой выбор: Scrum или Kanban? Делитесь своими примерами и наблюдениями в комментариях!