Что ты выберешь: спринт или доски? Правильного ответа не существует. В этой статье разберёмся, что лучше — Scrum или Kanban-метод, сравним их и расскажем о слабых сторонах каждого.
Основы Agile
Чтобы разобраться между Scrum и Kanban-методом, нам стоит откатиться к истокам — методологии Agile. Потому что Scrum и Kanban — это, можно сказать, «дети» Agile.
Agile в переводе с английского «гибкость» — ключевое слово в этой методологии управления проектами.
⚡ Основа Agile — молниеносная реакция на изменения в процессе работы, умение адаптироваться к ним и договариваться с заказчиком
Agile строится на базовых принципах:
- Итеративный подход — не нужно долго сидеть над задачей один на один и разрабатывать подробный план по достижению идеального результата. Сырой, но рабочий продукт уже сейчас важнее, чем идеальный в будущем. Сырой — не значит конечный. Продукт будут дорабатывать и обновлять в дальнейшем, но уже сейчас им можно пользоваться
- Никаких согласований — в команде все равны и одинаково заинтересованы в том, чтобы выпустить рабочее ПО и при этом не потратить на это половину своей жизни. Нет начальников, с которыми нужно согласовывать каждый этап. Это экономит время и силы
- Участники процесса базово понимают, как устроены смежные дисциплины. Таким образом, коллеги смогут быстро сориентироваться в сложных ситуациях. Также изучение нового помогает держать мозги в тонусе.
💡 Историческая справка: считается, что методология Agile появилась в первой половине XX века, но свой расцвет она получила позже — с развитием компьютерных технологий в конце 90-х. Но и тогда специалисты не до конца понимали, как построить процессы так, чтобы было быстро, практично, результативно и при этом комфортно.
Ключевая дата: 2001 год — 17 разработчиков собрались в Юте (штат США) и придумали Манифест Agile (Agile Manifesto) — свод правил, которые регламентируют работу разработчиков ПО и помогают достичь конкретного результата в срок и с минимальными потерями.
Создатели манифеста проанализировали ситуацию и пришли к выводу, что именно тормозит процесс работы. В список вошли бесконечная бюрократия и, как ни странно, чёткое планирование — когда нужно следовать конкретному плану без изменений.
Главные тезисы, которые легли в основу Agile-методологии:
1️⃣ Результат (рабочее ПО) важнее, чем вся документация по нему
2️⃣ Связь с заказчиком важнее, чем то, что написано в контракте
3️⃣ Работа в команде важнее, чем инструменты, которыми она пользуется
4️⃣ Готовность быстро меняться важнее, чем изначальный план
Позже образовался Альянс Agile, который продвигал методологию в массы — так появились книги и методички о работе. В том числе родились методы Scrum и Kanban.
Что такое Scrum и Kanban
Чтобы в следующий раз не планировать спринт вместо потока, обсуждаем ключевые отличия двух методов.
Scrum
Это фреймворк Agile, то есть свод правил, благодаря которому команда может организовывать хаотичную работу, следуя принципам методологии. Важно быть гибкими и чуткими, но при этом нужно строго контролировать процесс работы с помощью регулярных созвонов.
Регулярные встречи не дают сорвать сроки или не завершить задачу. А ещё так каждый из участников получает обратную связь от команды. Больше не придётся тратить время на поиск решения проблемы
🐋 Методология строится на четырёх китах: командная работа (чёткие роли) + промежуточные результаты (регулярные спринты) + обязательная и регламентированная структура (события) + артефакты (инструменты для визуализации работы).
Как это выглядит на практике
👊 Непробиваемая структура. Результат работы оценивают не в самом конце, а через короткие итерации (спринты), интервал между которыми около двух недель, но иногда может достигать и месяца. Даже созвоны в зуме каждый день тоже часть метода Scrum. Всё это в совокупности называют «событиями», «встречами» или «церемониями».
- Планирование спринта (Sprint Planning) — команда встречается до начала работы и составляет план на следующий период. Отбирает самое важное из всего списка задач по проекту и думает, каким образом будет это выполнять.
В конце встречи должен получиться прописанный бэклог — подробный список со всеми задачами на будущий спринт и критериями оценки результата
- Ежедневные встречи (Daily Scrum) — каждый день в одно и то же время и на том же месте команда собирается на 15 минут, чтобы рассказать, кто чем занимается, какой прогресс и где сложности. Это нужно, чтобы сразу решить возможные проблемы и ускорить работу
- Обзор спринта (Sprint Review) — проводят в конце спринта, чтобы подвести итоги: собрать обратную связь, оценить результаты и обсудить, как будет складываться работа в дальнейшем
- Ретроспектива (Sprint Retrospective) — тоже проводят в конце спринта, но с фокусом на «косяки», которые могли возникнуть в процессе работы. Участники анализируют ошибки, чтобы в будущем их не повторять
👥 Чёткие роли — Scrum подразумевает, что процесс работы над проектом строго разделён по ролям и у каждого своя ответственность.
- Владелец продукта (Product Owner) — знает, как должен выглядеть результат, формирует бэклог и отвечает за грамотную расстановку приоритетов
- Scrum-мастер — следит за порядком, не даёт никому ссориться из-за задач и проверяет, как все участники спринта соблюдают правила — например присутствуют на Daily и так далее
- Команда разработки — программисты, дизайнеры и тестировщики. Именно они регулярно встречаются, обсуждают продукт, задачи и отвечают за результат
🖌️ Артефакты — инструменты, которые помогают визуализировать процесс.
- Бэклог — все требования и задачи по конкретному продукту/проекту
- Бэклог спринта — те задачи, которые команда отобрала для работы во время планирования спринта
- Инкремент — результат каждого отдельного спринта. Это часть продукта, которую уже протестировали. Её уже можно показать миру
Ключевые показатели Scrum
Чтобы отслеживать эффективность работы, мы смотрим не только на закрытые задачи, но и на метрики — ниже расскажем, на какие стоит обратить внимание 😉
Скорость (velocity)
Номер один в списке ключевых показателей. Показывает, что команда успела сделать во время спринта, а также помогает планировать объём работ на будущее. Если уже известно, сколько в среднем уходит времени на спринт, то можно и спрогнозировать реалистичные дедлайны для заказчика.
Как считается
Нужно выделить две единицы измерения скорости.
🕑 Время — часы, которые ушли на работу
⭐ Story points — относительная оценка сложности задачи. Поставить её можно четырьмя способами, но приведём в пример метод Фибоначчи, когда каждой задаче присваивают баллы (1, 2, 3, 5, 8, 13, 21). Чем выше балл, тем сложнее задача.
Story points (SP) нужны для того, чтобы оценить, сколько сил уйдёт на одну задачу. Но сделать это наобум не получится. Нужно учитывать три вещи: объём работы, технические сложности и риски — то есть неопределённости, которые могут возникнуть в процессе
Посчитать скорость можно по-разному в зависимости от того, в чём её измеряешь — в часах или сторипойнтах.
Первый вариант — сложить общее количество часов, которые ушли на выполнение задач за время спринта. Второй вариант — сложить все сторипойнты. Но важно учитывать только те задачи, которые уже сделаны и приняты заказчиком.
Диаграмма сгорания задач (Burndown Chart)
Названа так, потому что с помощью графика можно посмотреть, сколько задач уже сгорело с начала спринта.
На графике две оси. На вертикальной — сторипойнты (или часы), которые нужно потратить на все задачи спринта, а на второй — дни, которые остались на работу.
Самое главное изображение на графике — две линии, которые расположены на диаграмме.
- Линия идеальной работы — идёт чётко по диагонали, и на неё нужно ориентироваться. Начинается с левого верхнего угла и идёт прямо по диагонали вниз к нижнему правому углу. Означает, что каждый член команды работает по плану, и именно так должен выглядеть успех.
- Линия фактической работы — показывает, как на самом деле идут дела, и может не совпадать с идеальной. Если часть реальной линии находится выше идеальной — значит, у команды проблемы и кто-то недорабатывает. Если опускается ниже — можно немного выдохнуть: работа идёт с опережением.
Накопительная диаграмма потока (Cumulative Flow Diagram)
Ещё один инструмент визуализации, который показывает на графике, в какой из колонок на Scrum-доске (расскажем далее, что это) больше всего задач — «Очередь» (голубой цвет), «Разработка» (сиреневый цвет), «Тестирование» (оранжевый цвет) или «Готово» (синий цвет).
На графике также две оси. Вертикальная — количество задач, которые взяли на спринт. Горизонтальная — время, за которое нужно всё успеть.
На накопительной диаграмме потока можно увидеть, как долго задача остаётся нетронутой или находится в работе. График помогает распределять работу между сотрудниками и избежать перегруза.
Capacity (ёмкость)
Показывает, сколько часов команда действительно тратит на спринт. В реальности у коллег могут быть другие задачи, да и человеческий фактор никто не отменял, например больничный.
Ёмкость помогает отследить, сколько своего рабочего времени команда готова посвятить исключительно задачам спринта и какую нагрузку может выдержать.
Как считается
По факту, нам нужно сложить рабочие часы на время спринта всех участников команды. Например: в команде 4 человека, и каждый может уделить проекту по 32 часа за спринт. Тогда общая ёмкость составит 4 × 32 = 128 часов. Если предположить, что 15% времени уйдёт на встречи, обсуждения и организационные дела, то реальная Capacity будет 128 × 0,85 = 108,8 часа (то есть примерно 109 часов).
Capacity — это подушка безопасности, которая не даст сорвать сроки, потому что считает рабочий день не как 8 часов, а как 6 — два часа оставляет «в уме» на экстренный случай.
Cycle time (время цикла)
Время, которое команда тратит на задачу от её начала до сдачи заказчику.
Как считается
Фиксируем, когда задача перешла в статус «В работе» и когда заказчик принял её. Считаем разницу — видим результат.
Метрика помогает проанализировать, на каком моменте может быть ступор, и скорректировать тайм-менеджмент, если что-то пошло не так.
Wasted Time (потерянное время)
Время, которое уходит в пустоту, например неэффективные встречи, долгое ожидание обратной связи, переключения между задачами или отвлекающие сообщения. В общем, всё, что как-то отвлекает внимание от целей и задач спринта.
Метрика нужна, чтобы трезво оценить, куда утекают драгоценные минуты, и научиться планировать время так, чтобы всё успевать на работе, а не доделывать по ночам.
Как считается
Нужно определить, какие задачи «пустые», каждый раз их отслеживать и фиксировать время, которое на них уходит. В конце спринта нужно сложить часы, удивиться результатам и посоветоваться с коллегами, как можно наладить рабочий процесс.
Ремарка: эта метрика хоть и хороша, но подходит для очень ответственных, храбрых и дисциплинированных спецов, которые не боятся взглянуть правде в глаза и готовы действительно всё фиксировать. Даже то, что им не хочется.
Что может пойти не так со Scrum
Что угодно. Несмотря на то что Scrum зарекомендовал себя как суперэффективный метод в работе, который не даёт шансов сорвать сроки, у него есть нюансы.
| ✅ Да | ❌ Но |
|---|---|
| Daily Scrum по 15 минут помогают трезво оценивать работу по проекту и получать обратную связь по текущим задачам, чтобы быстрее с ними справиться | Но у коллеги может быть по пять звонков в день, после которых сил на работу может вообще не быть.Если Daily длится 30 минут, то это уже не Scrum |
| Scrum — это гибкость | Но если требования по проекту меняются каждый день, то эффективность работы снижается.Придётся постоянно пересматривать план спринта и тратить на это время |
| Тесная связь в команде важна, чтобы помогать друг другу и анализировать результаты совместной работы | Но если в команде новичок, который не знаком со Scrum, то подстроиться под новый режим работы будет сложновато |
Kanban-метод
Kanban-метод помогает визуализировать работу по проекту — разделить его на этапы и распределять задачи таким образом, чтобы было легко управлять их потоком.
Один из принципов Kanban-метода — визуализация потоковых задач. Для этого существует Kanban-доска, которая изначально разделена на колонки: «Сделать», «В работе», «Готово».
В каждой колонке находятся карточки — это задачи, которые нужно довести до конца. В классическом виде это выглядит так:
| «Сделать» → То, что запланировано | «В работе» → То, что взяли в работу | «Готово» → То, что сделано |
|---|
Kanban-доски помогают не потеряться в огромном потоке задач и работать над ними последовательно. Более того, так ты сможешь отслеживать результат своей работы — ты буквально видишь, на каком этапе задача сейчас
Названия колонок можно изменить, но осторожно. Важно учитывать принцип Kanban-метода: каждая колонка — это стадия выполнения задачи, а название её иллюстрирует.
В карточке задачи независимо от того, в какой колонке она находится, должны быть:
- Описание
- Исполнитель
- Дедлайн
- Теги
- Приоритеты
Kanban-доска с колонками есть и в WEEEK. Вот так она выглядит.
Кстати, Kanban пользуется особой популярностью у наших коллег.
Kanban-каденции
Это регулярные встречи, во время которых команда обсуждает работу над проектом, выявляет узкие места и ищет пути решения проблем. Kanban-каденции помогают держать ритм, бороться с прокрастинацией и понимать, что вообще происходит с задачами.
‼️ Важно: ритуалы Scrum и Kanban-каденции — не одно и то же, хотя кажутся похожими.
- Kanban-каденции могут длиться по 20–30 минут. Команда встречается по потребности, а Scrum-meeting подразумевает жёсткий регламент. Например, Daily не может занимать дольше 15 минут
- Kanban-каденции — это встречи, на которых коллеги обсуждают не цели, а процесс. Scrum сконцентрирован на задачах спринта и их выполнении
Как Kanban-метод работает на практике
Несмотря на то что метод Kanban кажется достаточно простым, у него есть принципы, которые нужны, чтобы сделать его по-настоящему эффективным.
Принципы Kanban-метода
Если хочешь узнать больше, нажимай на «+» и читай пояснение ✏️
Что ещё важно помнить про канбан-метод:
| Важное напоминание | Пояснение |
|---|---|
| Проект — это ценность | Под проектом мы подразумеваем задачу для бизнеса или клиента, которую нужно довести до конца |
| Время на выполнение каждой задачи чётко определено | Доска разделена на колонки «Сделать» → «В работе» → «Готово» не просто так, а чтобы понимать, на каком этапе сейчас идёт работа по каждой задаче |
| У каждой колонки есть лимит задач — WIP-лимиты | Это значит, что ты не можешь взять в работу дополнительную задачу, пока не завершишь предыдущие.То есть в колонке «В работе» у тебя должно быть определённое количество карточек. Например, пять. Ты можешь взять в работу шестую задачу только тогда, когда в этой колонке освободится место — слот.Таким образом, ты сможешь доделать работу до конца и не перерабатывать |
| У каждой задачи запланировано время на её выполнение | Так можно прогнозировать сроки работы по проекту и называть заказчику адекватный дедлайн |
Ограничения Kanban-метода
Kanban, как и Scrum, подходит не всегда и не везде, его нельзя назвать универсальным решением в управлении проектами.
- Не подходит для больших команд. Если над проектом работает больше десяти человек, то может возникнуть путаница
- Если у коллег не развита самодисциплина, то работать будет сложно, даже при регулярных встречах
- Kanban-метод тяжело адаптировать для планирования долгосрочных задач. Он нацелен на то, чтобы получить результат в краткосрочной перспективе
Kanban и бережливое производство
Бережливое производство — это процесс управления проектами. Его суть — высокая эффективность и при этом минимальные потери.
Цель бережливого производства — создать ценность продукта для клиента
Под потерями подразумеваются: переработки, излишки продукта, недостаток качества и срыв сроков
Строится на концепции Kaizen — постоянные перемены к лучшему (придумали в Японии)
Kanban (в переводе с японского — "вывеска"/"табличка") придумали на заводе Toyota — инструмент сигнализировал, что на конвейере появилась ёмкость для новой работы. Также эти kanban (сигнальные карточки) выступали в роли ограничителей незавершённой работы.
Современный Kanban-метод, который сейчас распространён в IT, появился гораздо позже. Он заимствует идеи Kanban Toyota, но имеет свои принципы и практики, а фокус делает на визуализацию, WIP-лимиты и работу с метриками производственных систем.
Концепцию бережного производства сейчас применяют уже почти везде — на заводах, фабриках, в ретейле и даже в маркетинге и разработке.
Канбан-доска в бережливом производстве выполняет те же самые функции: благодаря WIP-лимитам сводит переработки к нулю, экономит время и даёт задачи по потребности (ты не сможешь начать работу над новой задачей, пока не освободится место под неё).
Виды Kanban-систем
Метод Kanban можно представить по-разному, как тебе удобно, хоть на бумаге или с помощью приложений. Отсюда вытекают два вида — физическая канбан-доска и цифровая. Какую выбрать — решать тебе.
🫶 Физическая
Место притяжения людей в офисе, но может занять место и в твоей комнате, если ты строишь грандиозные планы на жизнь. Доска в прямом смысле деревяшка или стена, а задачи на ней — стикеры .Все перемещения придётся делать ручками, как и записывать компоненты задачи на стикерах. Если что-то где-то нужно поменять, то это тоже должен делать ответственный за доску.
🤖 Цифровая
Место притяжения удалёнщиков. Доска — та же доска, только виртуальная (уже показали на примере, как это выглядит в WEEEK).Задачи на карточках можно редактировать в любой момент или даже удалить, если нужно. А ещё расставлять приоритеты, проставлять теги и оставлять бесконечное множество комментариев. Также карточки удобно перемещать между колонками.
Способы измерения эффективности Kanban-метода после внедрения
Оценить работу в канбан-досках очень легко — достаточно взглянуть на эти метрики:
- Cycle Time — сколько времени ушло на одну задачу от старта до завершения
- Lead Time — полный жизненный цикл задачи с того момента, когда её поставили, и до её завершения. Включает в себя и то время, которое задача провела в ожидании
- Flow Efficiency (эффективность потока) — показывает в процентах, сколько времени задача реально находилась в работе, а сколько — ждала, пока ты на неё кликнешь
- Throughput (пропускная способность) — показывает, сколько задач команда выполняет за определённый период
- Work in Progress (WIP) — количество задач, которые находятся в работе
Что может пойти не так с Kanban-методом
Как и в случае со Scrum, ответим: «Что угодно». Совершенных и идеальных методологий управления проектами не существует. Вот какие подводные камни могут быть у Kanban-метода.
| ✅ Да | ❌ Но |
|---|---|
| Разделить доску на колонки, установить WIP-лимиты и проставить приоритеты — почти 100 % успеха | Но если тебя никто не проверяет, то есть риск скатиться в прокрастинацию, потому что Kanban — это больше про дзен, а не про жёсткую дисциплину |
| Когда я перетаскиваю карточку из одной колонки в другую, то вижу результат и могу отследить, на каком я сейчас этапе | Но без чётких сроков и контроля со стороны вся моя работа превратится в бездумное перетягивание карточек, а это уже противоречит методологии Kanban, где ценность продукта превыше всего |
| Можно ввести канбан-метод по всем канонам. Устраивать обязательные встречи, установить лимиты, сроки работ и ожидать соответствующего результата | Но без понимания особенностей команды, продукта и его целей всё превращается в формальное выполнение задач. Это не делает процесс эффективнее, а только мешает |
| Колонки на Kanban-доске помогают разделить потоковые задачи на этапы и не топтаться на месте | Но если увлечься и создать дополнительные колонки, то они могут помешать задаче дойти до финишной прямой |
| Здорово, что Kanban-метод помогает непрерывно улучшать рабочие процессы | Но чтобы это действительно сработало на практике, доску нужно постоянно обновлять и адаптировать под изменения проекта. Не получится сделать одну универсальную доску для всех и забыть, надеясь, что команда будет работать на автомате самостоятельно |
В чём разница между Scrum и Kanban-методом
Вместо тысячи слов сравнили две методологии управления проектами по чётким критериям. Можешь сделать скриншот на всякий случай (вдруг пригодится) и читать дальше.
| Scrum | Kanban-метод | |
|---|---|---|
| Источник появления | Фреймворк Agile — появился у разработчиков. Считается, что Scrum — это жёсткая реакция на быстро меняющиеся условия по проекту, когда результат нужен уже сейчас | Возник на производстве Tayota как способ управлять потоковым производством. Сейчас Kanban-метод адаптировали для IT и других отраслей |
| Основная идея | Результат каждого спринта — сырой продукт (или его часть), но им уже можно пользоваться. Обратная связь не менее важна, так как с помощью неё корректируются слабые места | Процесс должен постоянно улучшаться, при этом сама работа должна занимать меньше времени и не провоцировать материальные, временные и человеческие потери на производстве |
| Ключевые показатели | Скорость (Velocity) — то, что успели сделать за спринт | Время цикла (Cycle Time) – сколько времени ушло на задачу от начала работы до её завершения.Пропускная способность (Throughput) — количество задач, которые появились в колонке «Готово» за определённое время |
| Команды | Кросс-функциональная команда. Может работать самостоятельно. При этом есть чёткие роли, и у каждого участника своя зона ответственности.На время спринта состав команды жёстко фиксированный | Состав команды может быть гибким. Если ты даёшь доступ всем, то в твою доску может зайти кто угодно.Также ты можешь работать с Kanban-досками в одиночку |
| График | Жёсткий, итеративный. Процесс работы делится на строго фиксированные по времени спринты, интервал между которыми может быть от одной недели до месяца | Гибкий, непрерывный. Нет фиксированных итераций, задачи поступают в работу потоком и завершаются по мере возможности |
| Роли | Чётко распределены, и у каждой роли — своя ответственность: • Владелец продукта • Скрам-мастер • Команда разработки | Нет предписанных ролей. Да они и не нужны |
| Встречи | Обязательные и регламентированные: • Планирование спринта • Ежедневный скрам • Обзор спринта • Ретроспектива спринта | Не обязательны, но лучше периодически встречаться с командой, чтобы обсудить рабочие моменты. На них можно выявить узкие места и найти решения, которые помогут улучшить сам процесс |
| Разделение на этапы | Работа делится на спринты. Команда обязана выполнить весь запланированный объём работы к концу спринта | Работа не делится на итерации. Задачи поступают в бэклог и выбираются в работу, когда для них есть место в колонке (ограничение WIP) |
| Приоритеты | За приоритеты отвечает владелец продукта. На спринт команда берёт задачи с самого верха | Приоритеты устанавливает менеджер, но команда может брать следующую задачу из готовой к работе очереди, учитывая приоритет |
| Итерации и непрерывность | Итеративный подход. Работа выполняется фиксированными спринтами | Непрерывный поток. Задачи выполняются и сдаются по готовности |
| Методы | Ритуалы: планирование спринта, ежедневные встречи, обзор спринта и ретроспектива | • Управление потоком • Визуализация задач с помощью канбан-доски • WIP-ограничения |
| Визуализация | В классическом варианте не предусмотрена, однако в большинстве случаев задачи распределяются на Scrum-доске, которая работает по принципу Kanban, но есть нюанс: после каждого спринта задачи сбрасываются | Kanban-доска постоянная. Колонки отражают реальные этапы, через которые проходит задача.Название колонок можно придумать любое, но принцип должен сохраниться |
| Отношение к изменениям | Изменения во время спринта возможны, но при условии, что они не влияют на его цели. В противном случае изменения в продукте будут учтены в следующем спринте | Изменения можно вносить в любое время |
Scrum или Kanban: рекомендации по выбору
Собрали несколько тезисов по каждой методологии управления проектами, чтобы тебе было проще выбрать.
Когда подходит Scrum
Когда подходит Kanban
Kanban-метод широко используется в маркетинге, службе поддержки и других сферах, где не требуется регулярная отчётность и жёсткая дисциплина.
Scrumban: гибридный подход Scrum/Kanban
Возможно, в любом другом случае тебе бы пришлось поломать голову над выбором методологии, но, к счастью, умные люди сделали это за нас — создали Scrumban. Эта методология сочетает в себе лучшее из каждой.
Дисциплина и регулярные спринты (Scrum) ➕ Доска с задачами и гибкость (Kanban-метод) 🟰 Scrumban
Как это выглядит на практике
Команда всё ещё созванивается по рабочим задачам и проводит спринты. Однако она уже сама решает, какие именно встречи оставить. Например, она может отказаться от ретроспективы или Daily.Все задачи формируются на Scrum-доске — принцип тот же самый, что и у Kanban. WIP-лимиты обязательны. Так команда может отслеживать свои задачи, не теряться и синхронизироваться с другими.
В списке метрик не только скорость выполнения работ, но и кое-что из Kanban-метода — Cycle Time, Lead Time, Throughput.
💊 Итого: волшебной таблетки в управлении проектами не существует (как и в принципе). Нет идеальных методологий — есть только твоя профессиональная чуйка и возможность комбинировать методы, подстраивая их под нужды проекта, команды и заказчика.
Подписаться 
