На доске двадцать задач. Разработчики заняты, заказчик ждёт, а законченный результат всё время отодвигается. В такой ситуации хочется выбрать «правильную методологию» и наконец наладить работу. Но Scrum и Kanban помогают по-разному: первый задаёт структуру совместного развития продукта, второй позволяет управлять потоком работы и замечать, где он останавливается.
Мы в Гуси-Лебеди предлагаем начинать с вопроса: что именно сейчас мешает команде? Нужно регулярно проверять полезное изменение продукта или справляться с постоянно поступающими запросами? Ниже сравним подходы, разберём две условные рабочие ситуации и покажем, какие договорённости нужны кроме красивой доски.
Scrum и Kanban: в чём разница и что выбрать для команды
Scrum организует работу над сложным продуктом через короткие периоды, которые называют спринтами. У команды есть цель, определённые ответственности и события для планирования, проверки результата и улучшения процесса. Kanban помогает видеть путь каждой задачи от начала до завершения, ограничивать незавершённую работу и управлять её движением. Доску можно использовать в обоих подходах, поэтому по виду столбцов метод не определить.
Agile тоже не является третьим видом доски. Это ценности и принципы гибкой разработки. Для выбора процесса полезнее обсудить конкретную работу, чем спорить, какое название звучит современнее.
| Что сравниваем | Scrum | Kanban |
|---|---|---|
| Как организована работа | Спринты вокруг цели и полезного результата | Поток задач с явными правилами начала, переходов и завершения |
| Как выбирают следующую работу | На планировании формируют цель, выбирают работу и план её выполнения | Берут следующую задачу с учётом приоритета и свободной мощности |
| Что делать с изменением | Уточнять план, сохраняя цель спринта и качество | Следовать согласованной политике приоритета и ограничениям потока |
| Кто за что отвечает | Product Owner, Scrum Master и Developers имеют определённые ответственности | Новые обязательные роли не задаются, действующие ответственности нужно сделать понятными |
| Когда выпускать результат | Готовый результат можно передать до окончания спринта | По правилам поставки, принятым для данного потока |
Ситуация первая: команда развивает личный кабинет. Это условный пример. Нужно дать клиенту возможность повторить прошлый заказ. Пока неизвестно, какой сценарий будет удобнее, поэтому полезно получить работающий вариант, показать его пользователям и решить, что менять дальше. Scrum может дать такой работе понятный ритм и общую цель. Спринт здесь имеет смысл благодаря проверяемому результату, а не просто дате в календаре.
Ситуация вторая: команда сопровождает несколько сайтов. Приходят ошибки, просьбы обновить материалы и небольшие доработки. У обращений разные сроки и причины срочности. Kanban позволяет видеть очередь, текущую работу, ожидание клиента и готовые изменения. Задача управления состоит в том, чтобы запросы доходили до результата, а специалисты не начинали всё одновременно.
Это ориентиры для обсуждения, не правило «новый продукт только Scrum, старый только Kanban». Существующий продукт тоже можно развивать по Scrum. А при создании нового сервиса можно использовать Kanban, если команда осознанно организует поток и обратную связь. Отдельно посмотрите на зависимости: если любое решение неделями ждёт внешнего согласования, смена названия процесса это ожидание не уберёт.
Как работает Scrum: цель спринта важнее списка карточек
В официальном Scrum Guide спринт описан как период фиксированной длины не больше месяца. Две недели могут быть удобным выбором команды, но это не обязательная длительность для всех проектов.
Вернёмся к примеру с личным кабинетом. «Сделать десять задач» не объясняет, зачем они нужны. Цель «клиент может повторить прошлый заказ без повторного заполнения всех данных» связывает работу дизайнера, разработчиков и тестировщика. Команда выбирает подходящий объём, составляет план и уточняет его по мере появления новой информации.
Общий бэклог продукта содержит будущую работу. Product Owner отвечает за управление им и максимизацию ценности продукта. Developers выбирают, как выполнить работу, создают пригодный к использованию результат и адаптируют план. Scrum Master отвечает за понимание Scrum и эффективность команды в его применении. Назначить одного человека «главным по доске» недостаточно, если продуктовые решения и ответственность за качество остаются неопределёнными.
Как выглядит рабочий цикл. На Sprint Planning обсуждают ценность ближайшего спринта, выбирают работу и способ её выполнения. Daily Scrum помогает Developers проверить продвижение к цели и скорректировать план. Sprint Review нужен для совместного анализа результата и дальнейшего направления продукта. На Sprint Retrospective разбирают, как повысить качество и эффективность работы. Эти события решают разные задачи; ежедневный отчёт начальнику не заменяет их смысл.
«Почти готово» не равно готовому результату. Если повторный заказ работает только на компьютере разработчика, а ошибки не проверены, показывать закрытые карточки рано. Нужны общие критерии качества, которые команда действительно соблюдает.
В Scrum такой общей договорённостью служит Definition of Done. Она описывает состояние результата, который соответствует требованиям качества. Пригодный к использованию Increment можно передать пользователям до конца спринта. Ждать Sprint Review ради разрешения на выпуск не требуется.
А если посреди спринта появилась срочная задача? Нельзя просто дописать её поверх прежнего объёма и считать, что ничего не изменилось. Developers и Product Owner обсуждают влияние на цель: можно ли уточнить решение, пересогласовать объём или отложить менее важную работу? Изменения, которые ставят Sprint Goal под угрозу, недопустимы. Если цель потеряла актуальность, отменить спринт может Product Owner. Полного запрета на уточнение всех задач внутри спринта в руководстве нет.
Velocity, Story Points и график сгорания задач могут быть вспомогательными инструментами. Они не являются обязательными требованиями Scrum Guide. Мы советуем сначала наладить цели, качество и обратную связь, а затем выбирать способы планирования. Сравнивать сотрудников по набранным баллам или увеличивать их ради отчёта бессмысленно: важен результат для пользователя.
Как настроить Kanban: правила потока, WIP и срочная работа
Перетаскивать карточки между «Сделать», «В работе» и «Готово» удобно, но для управления потоком этого мало. В Kanban Guide используются определение и визуализация рабочего процесса, активное управление текущей работой и улучшение потока. Сначала договоритесь, какие задачи проходят через систему, где их начало и конец, какие состояния находятся между ними и по каким правилам можно двигаться дальше.
- Определите, когда работа начинается. Для обращения по сайту это может быть момент, когда команда приняла его в выполнение. Просто полученная заявка и уже начатая задача должны различаться.
- Покажите реальный путь. Если после разработки нужна проверка и согласование клиента, отразите их. Карточка «Готово», которая ещё ждёт приёмки, скрывает незавершённую работу.
- Ограничьте незавершённую работу. WIP означает число начатых, но ещё не завершённых задач. Лимит задаёт правило, когда можно брать следующую. Его выбирают с учётом данного процесса и проверяют на практике.
- Согласуйте исключения. Кто подтверждает срочность, что происходит с текущими задачами и когда команда пересматривает приоритет? Слово «срочно» в сообщении не должно автоматически отменять все договорённости.
- Следите за ожиданием. У блокировки должны быть понятная причина и следующий шаг. Ожидающую задачу нельзя считать завершённой только потому, что специалист сейчас не может её продолжить.
В нашем условном сопровождении сайтов разработчики заканчивают доработки, но тестировщик не успевает их проверять. Если выдавать разработчикам всё новые карточки, очередь на проверку будет оставаться проблемой. Сначала стоит выяснить, почему она образовалась: не хватает данных для проверки, сложен стенд, много возвратов или объём превышает доступную мощность. Решение принимают по наблюдению, а не по предположению, что кто-то недостаточно занят.
При заполненном WIP-лимите команда сначала помогает завершить начатое или снять препятствие. Именно наличие свободной мощности позволяет взять следующую задачу. Kanban не означает, что любую новую просьбу нужно немедленно запускать в работу. И универсального правила «ровно одна карточка на каждого сотрудника» здесь тоже нет.
Что измерять. Четыре базовых показателя потока: WIP, количество завершений за единицу времени (Throughput), возраст ещё выполняемой задачи (Work Item Age) и время от её начала до завершения (Cycle Time). Время цикла включает ожидание между согласованными точками, это не только часы активной работы специалиста. Возраст незавершённой карточки помогает замечать затяжные задачи ещё до их закрытия.
Для ожиданий по срокам используют SLE: период и вероятность завершения, основанные на истории данного потока. Без истории первоначальное ожидание остаётся предположением и требует проверки. Нельзя взять среднее время другой команды и представить его клиенту как гарантированный срок. При сопровождении сайта отдельно согласуйте реакцию на обращение, приоритет инцидента и условия завершения: это разные договорённости.
Можно ли совместить подходы и как проверить, что процесс помогает
Да, практики Kanban можно применять внутри Scrum. В руководстве Kanban для Scrum-команд подчёркнуто: они дополняют Scrum, а его правила сохраняются полностью. Команда может работать со Sprint Goal, проводить необходимые события и одновременно ограничивать WIP, разбирать блокировки и отслеживать возраст задач.
Например, команда личного кабинета сохраняет спринты, но добавляет на доску состояние «Ждёт проверки» и договорённость о незавершённой работе. На Daily Scrum становится видно, какие изменения мешают получить нужный результат. Это осмысленное дополнение. А отмена всех событий, сохранение названия «спринт» и ежедневное изменение цели создают уже другой процесс. Название Scrumban само по себе не объясняет, какие правила вы используете.
Начните проверку с исходной проблемы. Запишите, что хотите изменить: раньше замечать зависшие обращения, удерживать цель разработки, уменьшить ожидание проверки или получать понятную обратную связь. Сохраните доступные наблюдения до изменения правил. Если их пока нет, сначала начните собирать данные, чтобы последующее сравнение имело основание.
- Для Scrum обсуждайте достижение цели, пригодность созданного результата и то, какие выводы изменили дальнейшую работу.
- Для Kanban смотрите на движение задач между реальными точками начала и конца, возраст текущей работы, блокировки и завершения.
- В обоих случаях проверяйте возвраты и качество. Быстро закрытая карточка, которую приходится переделывать, требует отдельного разбора.
Не сравнивайте команды по одному числу закрытых карточек. Исправление подписи и интеграция сервиса различаются по содержанию, а правила дробления задач способны изменить счётчик без изменения результата. Аналогично, количество встреч не показывает, стало ли легче принимать решения. Выберите конкретное препятствие, измените связанную с ним договорённость и проверьте, что произошло.
Если нужно организовать разработку веб-сервиса, начните обсуждение с цели продукта, ответственного за приоритеты, критериев качества и внешних зависимостей. Содержание полезного изменения помогают описать user story и критерии приёмки. После этого выбор Scrum, Kanban или их совместного применения становится предметным: понятно, какую проблему решают выбранные правила и как команда заметит результат.