Scrum kanban что это

Сравнение Scrum и Kanban. Какая методика Agile подойдет вам?

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

Просмотр тем

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

Agile — это набор идеалов и принципов, которые служат нам ориентиром. DevOps — это способ автоматизации и интеграции процессов команд разработчиков и операционных команд. Внедряя Agile и DevOps, следуйте методике Kanban или Scrum. Каждая из них предлагает свой вариант управления многосоставной работой.

Указать на различия между методологиями scrum и kanban несложно, но это даст лишь поверхностное представление. Хотя методологии различаются, их принципы в целом одинаковы. Обе помогают улучшить качество продуктов (и сервисов) и избавляют от множества проблем.

Итак, на чем мы остановились?

Agile — это структурированный итеративный подход к управлению проектами и разработке продуктов. В нем учитывается непостоянный характер разработки продуктов. Самоорганизующиеся команды, выбравшие этот подход, получают возможность реагировать на изменения, не отклоняясь от намеченного пути. В наши дни agile не дает особого преимущества перед конкурентами. Сегодня просто невозможно разрабатывать продукт в течение нескольких месяцев или даже лет в условиях полной секретности. А значит, сейчас как никогда важно работать правильно.

Суть Kanban в визуализации работы, ограничении объема незавершенной работы и достижении максимальной эффективности (или скорости). Kanban-команды стремятся максимально сократить время, которое уходит на выполнение проекта (или пользовательской истории) от начала до конца. Для этого они используют доску Kanban и непрерывно совершенствуют свой рабочий процесс.

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

Scrum

Kanban

Регулярные спринты с фиксированной продолжительностью (например, 2 недели)

В конце каждого спринта

Владелец продукта, scrum-мастер, команда разработчиков

Обязательных ролей нет

Время выполнения, время цикла, объем незавершенной работы (WIP)

Отношение к изменениям

В ходе спринта команды не должны вносить изменения.

Изменение может произойти в любой момент

Scrum — структурированный agile-подход

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

График Scrum

В Scrum высокий темп работы достигается путем ее деления на спринты продолжительностью от двух до максимум четырех недель с точными датами начала и окончания. Из-за узких временных рамок сложные задания приходится делить на более мелкие истории, и команда быстрее учится. Сможет ли команда за это время поставить пригодный для использования код? Вот в этом — главный вопрос.

Ключевыми точками в спринте являются собрания по планированию спринта и по обзору итогов спринта, а также ретроспективы. Кроме того, в ходе спринта проходят ежедневные scrum-совещания (стендапы). Эти scrum-собрания не отнимают много сил и проводятся на регулярной основе.

Подходы к релизу

Сейчас при использовании scrum продукт нередко выпускается по ситуации, но долгое время рекомендовалось выпускать продукт в конце каждого спринта. Команды ставят цель для каждого спринта (цель спринта) и на собрании по обзору итогов спринта принимают решение, выпускать результат работы или нет.

Роли в Scrum

В scrum четко обозначены три роли.

Кто руководит командой scrum? По факту никто. Команды scrum проповедуют принцип самоорганизации; в них все участники равны, хоть и исполняют разные обязанности. Команду объединяет общая цель: поставить ценный продукт клиентам.

Ключевые показатели

Скорость — сумма очков оценки сложности, отражающая объем работы, которую выполнили за спринт. Это базовый показатель для команд scrum. От него зависит, какой объем работы команда возьмет на себя в будущих спринтах. Если команда в среднем за спринт может заработать 35 очков оценки сложности (скорость = 35), она не примется за бэклог спринта, содержащий задач на 45 очков.

Отношение к изменениям

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

Подробнее о методологиях scrum см. в статье Что такое scrum?.

Kanban — непрерывное совершенствование, гибкие процессы

Суть Kanban — в визуализации работы, ограничении объема незавершенной работы (WIP) и быстром перемещении задач от стадии «Выполняется» на стадию «Завершено».

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

Модель Kanban

В основе kanban лежит непрерывная структура рабочего процесса, дающая командам свободу действий и возможность меняться вместе с изменениями приоритетов. Рабочие задачи представлены карточками на доске kanban и перемещаются из одной стадии рабочего процесса (столбца) в другую. Обычно рабочий процесс подразделяется на стадии «Предстоит сделать», «В процессе», «На проверке», «Заблокировано» и «Завершено». Но это не самый интересный способ разбить процесс.

Возможность создавать собственные столбцы в зависимости от того, как работает ваша команда, — лучшая особенность Kanban. Моя команда поставляет контент, поэтому задачи проходят столбцы (упрощенно) «Бэклог», «Приоритеты расставлены», «Схема набросана», «Написание», «Оформление», «Техническая экспертиза» и «Поставлено». С помощью нашей доски мы узнали, что поставляем примерно одну порцию контента в неделю, и поняли, где у нас проблемные места. (Да, это именно «Техническая экспертиза»!)

Подходы к релизу

В kanban обновления выпускаются по мере готовности; регулярный график или заранее определенные сроки отсутствуют как таковые.

Теоретически в рамках kanban не требуется устанавливать точный срок для завершения задания. Если задание выполняется раньше (или позже), результат выпускается по мере необходимости: для выпуска не нужно ждать контрольной точки, например собрания по обзору итогов спринта.

Роли в Kanban

Доска Kanban принадлежит всей команде. Некоторые команды привлекают к участию тренера по agile, но Kanban, в отличие от Scrum, не предусматривает роль «kanban-мастера», который отвечал бы за устранение шероховатостей в процессе работы. Команда несет коллективную ответственность за совместное выполнение заданий на доске и поставку результатов.

Ключевые показатели

Время выполнения и время цикла — важные показатели для команд kanban. Они отражают, сколько в среднем уходит времени на выполнение работы от начала до конца. Сокращение времени цикла говорит об успехе kanban-команды.

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

Другое средство борьбы с проблемными местами — лимиты незавершенной работы (WIP). Они позволяют ограничить максимальное количество карточек, которые могут находиться в любом столбце одновременно. Когда лимит WIP достигнут, специальный инструмент, например Jira Software, помечает этот столбец, и команда направляет свое внимание на эти задачи, чтобы передать их на следующие стадии.

Отношение к изменениям

В kanban рабочий процесс можно менять в любой момент. В зависимости от приоритетов новые рабочие задачи можно добавлять в бэклог, а существующие карточки — блокировать или вовсе удалять. В случае изменения производительности команды можно соответствующим образом скорректировать лимит WIP и изменить рабочие задачи. Суть kanban — в гибкости.

Подробнее о методике kanban см. в статье Что такое kanban?.

Сравнение инструментов Scrum и Kanban

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

Только после того, как вы освоили принципы scrum и пришли к выводу, что scrum полностью отвечает вашим потребностям, следует выбирать оптимальный инструмент scrum. То же можно сказать и про kanban. Конечно, наше мнение предвзято, но мы считаем, что Jira Software, лучший инструмент для разработки ПО, используемый agile-командами, обеспечивает любые потребности.

Jira позволяет создавать проекты специально под scrum и kanban, чтобы вы могли реализовывать принципы каждой методологии. Кроме того, вы всегда можете обратиться за помощью к нашим руководствам по применению scrum с помощью Jira Software и применению kanban с помощью Jira Software.

Kanban или Scrum — не можете выбрать?

Применять Scrum и Kanban — значит следовать всем правилам Agile. Эти методики прошли проверку временем и, откровенно говоря, им сложно что-либо противопоставить. Переиначив известный девиз IBM, можно сказать, что еще никого не уволили за выбор Scrum.

Но решение необязательно должно быть категоричным. Сотни команд используют гибридные модели, разработанные под влиянием и Scrum, и Kanban. В Jira Software мы предусмотрели все необходимое и создали проекты команды.

Проекты команды, как видно из названия, позволяют командам самим выбирать возможности Agile, которые им нужны. Это могут быть элементы Scrum, Kanban или их сочетание. Необязательно брать за основу одну методологию в первый же день работы. В проектах команды можно поэтапно добавлять все более и более мощные возможности по мере понимания того, что подходит команде (а что нет).

Выбирая проект команды Scrum или Kanban, вы не рискуете, ведь шаблоны обоих типов можно дорабатывать с учетом потребностей команды.

Что бы вы ни выбрали, не спешите менять методологию. Пусть какие-нибудь рабочие задачи из бэклога пройдут весь путь до стадии «Завершено», и только потом спросите команду, что удалось, а что нет. Знакомьтесь со Scrum и Kanban, задавайте эти вопросы, и в конечном счете вы познаете радость следования Agile.

Источник

Разбор Scrum и Kanban. Что выбрать?

Scrum — быстрая разработка сырых User Stories.
Kanban–медленная разработка проработанных User Stories.

Немного утрировано, но так легче разобраться, когда лучше использовать Scrum, а когда Kanban. Оба Agile подхода позволяют гибко управлять созданием и развитием продукта, но отличий у них намного больше.

Дисклеймер: мною написанный текст лишь мое собственное мнение и он не претендует на истину. Статья появилась на основе интервью в продуктовых командах и в процессе создания и развития продуктов по Scrum и по Kanban.

Моя цель — прояснить ситуацию с двумя подходами, помочь вам сэкономить время и сделать правильный выбор.

Мы не будем рассматривать все ритуалы Scrum и Kanban. Но исследуем почему применить Scrum удается не всем, и почему чаще всего лучше использовать Kanban.

Если даже один ритуал фреймворка не выполняется — это уже не Scrum. Да, в жизни идеальных условий не бывает, но ритуалы придумали не для галочки. Kanban не такой требовательный, и поэтому легче прижился в продуктовых командах. В то же время, Scrum более модный, и в желании не отставать от трендов появился народный SсrumBan (Scrum + Kanban).

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

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

Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Процесс примерно такой:
— оценка US и запуск спринта;
— разбивка US на задачи;
— ежедневные встречи (Stand up);
— фиксирование скорости команды (в Story Points);
— уточнение бэклога продукта;
— релиз (выпуск обновленного продукта);
— обзор спринта;
— ретроспектива.
Мы не тратим время на блок-схемы и на согласования, но тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.

Да, задачи не согласованы и не проработаны так тщательно, как, например, в Kanban. Но мы потратили всего 2 недели. Даже если ошиблись с гипотезой (что часто бывает), мы не растягивали процесс во времени и обошлись ресурсами небольшой команды (Product Owner, Scrum Master, Dev team).

Работа по Scrum это бесконечный процесс формирования и валидирования гипотез. Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Тем лучше это будет сказываться на продукте.

Шагая в неизвестность, необходимо устранять любые неопределенности, например: скорость команды. Нам важно знать когда мы сделаем обновление продукта и когда соберем обратную связь. Если в итоге гипотеза окажется неверна, будет поздно. Поэтому мы добросовестно выполняем все ритуалы. Например Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе, чтобы в следующем спринте равномернее закрывать задачи. В таком ритме это жизненно необходимо.

Подробнее о фреймворке Scrum здесь

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

Один цикл, от поступления задачи до ее выпуска на продуктиве, может затрагивать широкий круг специалистов из разных команд:
— анализ и разработка блок-схем;
— согласование со всеми заинтересованными лицами (ЗЛ);
— UX/UI дизайн;
— backend разработка;
— frontend разработка;
— тестирование;
— доработка;
— релиз (выпуск обновленного продукта).
Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Например: скопилось много задач по дизайну, и разработчики сидят без дела, скорей всего команде нужны еще дизайнеры. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать. Это сделает процесс еще прозрачнее и разработчики не будут тратить время на переключение с одного таска на другой.

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

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

В крупных компаниях руководство или заказчики требуют список задач на месяцы вперед. Если вы делаете продукт на внешний рынок и используете Scrum, то ваш список задач может выглядеть примерно так:
— Увеличить Retention на x% к дате n;
— Повысить NPS на x значений к дате n;
— Повысить LTV на x% к дате n.

Подробнее о полезных метриках здесь

Чувствуете как непросто принять фактически отсутствие плана? Если мы будем прописывать конкретные задачи и функционал, мы сами себя ограничим. Что важнее, сделать продукт с набором функций или продукт, который достигает product/market fit? Когда клиенты выстраиваются в очередь. Небольшое изменение в фокусе и вы уже создаете не функции, а продукт с конкурентными преимуществами, соответствующий потребностям рынка.

Подробнее о product/market fit здесь.

Никаких конкретных задач, только улучшение показателей продукта, потому что каждые 2 недели вы будете пересматривать бэклог опираясь на полученные данные. Стратегическая цель от этого не меняется — улучшить метрики и повысить лояльность ваших пользователей. А что может быть важнее? Тем более когда вы выпускаете сырые US на продукте. Да, мы будем проводить интервью с потенциальными клиентами перед началом работ, но окончательную точку, в отношении вашей гипотезы поставят только метрики продукта и обратная связь пользователей.

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

Если вы решились идти по Scrum, помните, что команда должна быть кросс-функциональной. Компетенций должно быть достаточно для выполнения полного объема работ с минимальным привлечением сторонних команд. Полное погружение в один продукт/сервис/проект. Иначе не получиться давать оценку US в Story Points и фиксировать скорость, так как вы отвечаете только за часть функционала. Не сможете контролировать время выхода релиза и вовремя получать данные. Обычно это приводит к скоплению не проработанных и не проверенных US в продукте, и к его закрытию в итоге.

Перед запуском первого спринта по Scrum расскажите о роли каждого участника команды (SM, PO и Dev team) и абсолютно о всех ритуалах и артефактах (их очень много). Не забудьте объяснить для чего они нужны, чтобы осознанно и регулярно их выполнять. И лишний раз убедиться, что Scrum вам действительно подходит.

Если все же сомневаетесь, ниже список из 10 пунктов, когда Scrum, скорей всего не подойдет:

1. Команда не видит смысла в некоторых ритуалах Scrum.

2. Команда не кросс-функциональна, выполняет только часть US.

3. Не настроены метрики продукта (Retention и LTV) или настроены, но не анализируются (если продукт ориентирован на внешний рынок).

4. Product Owner самостоятельно или совместно с заказчиком принимает решение куда развивать продукт не опираясь на обратную связь от пользователей и анализ метрик продукта (если продукт ориентирован на внешний рынок).

5. В текущий спринт вам постоянно подкидывают новые задачи.

6. Роли не зафиксированы, и каждый участник команды может выполнять не одну роль.

7. Команда работает над двумя и более продуктами.

8. Команда не фиксирует скорость, не анализирует Burn Down Chart и вообще не видит в этом смысла.

9. Акцент на качестве и согласованости, а не на скорости команды, метриках продукта и обратной связи от пользователей.

10. Road map в виде конкретных задач, а не в виде улучшения показателей продуктовых метрик.

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

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

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

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

Хорошо если ScrumBan вам помогает, но чаще всего это не так. Команды выполняют ресурсоемкие ритуалы Scrum и не видят в них смысла. В этом случае лучше чередовать оба подхода и в конечном счете определиться с одним из них.

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

Поделитесь, что вы используете Scrum, Kanban или ScrumBan? Буду рад любой обратной связи моя страница в Facebook.

Источник

Чем Канбан отличается от Scrum, и причем тут Agile

Когда-то давно Скрам и Канбан органично жили под одним брендом Agile.
Однако, по мере развития Канбан-метода, его создатели поняли, что этот должен базироваться на других принципах, нежели Scrum. Было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно, и надо его из-под «зонтика Agile» вывести

В этих нюансах не так просто разобраться тем, кто впервые интересуется Scrum и Канбан и поэтому мы решили написать эту статью, чтобы расставить все точки над «Ё».

Рассмотрим основные различия между Kanban-методом и фреймворком Scrum с точки зрения смысла, назначения и практики применения этих подходов.

Разница с точки зрения смысла

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

Kanban-метод похож на ящик с инструментами. Вы можете брать только что-то одно, или все сразу — решать вам. Каждый инструмент приносит свою пользу. Выбор инструмента зависит лишь от вашей готовности его применять. Есть разные степени зрелости применения Канбан-метода, и на каждом уровне организация использует те или иные его элементы и их сочетания.

Разница с точки зрения целей

Scrum изначально создавался, чтобы быстро разработать «то, не знаю что» — какой-то инновационный продукт, подобных которому может еще даже в мире не существует. В этом главная цель и назначение Scrum.

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

Можно конечно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility

То есть, применение Канбан-метода стратегически нацелено на изменения во всей компании, для обеспечения долгосрочной устойчивости и гибкости на рынке (Business Agility). А главной целью фреймворка Scrum является разработка нового инновационного продукта.

Разница с точки зрения принятия решений

Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.

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

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

Для ускорения принятия решений и достижения наилучших результатов Scrum делает ставку на командный подход.
Чтобы Scrum заработал, нужно вовлечение всех участников Scrum-команды — Владельца Продукта, Scrum-мастера и Разработчиков.

Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Scrum-командой, а не каким-то одним руководителем или менеджером.

Разница в смысле встреч и способе их проведения

Так как. Scrum делает ставку на командный подход, то все встречи в Scrum рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений.

Каждая встреча Scrum нацелена на одно из двух:

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

Канбан-метод смотрит на встречи иначе.

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

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

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

По итогу каждой встречи менеджер сервиса получает информацию для дальнейшего улучшения рабочих процессов и принимает управленческие решения

Разница с точки зрения предусловий

Чтобы Scrum начал приносить пользу, нужно сделать многое:

Только при выполнении этого, довольно длинного, списка условий Scrum может дать ожидаемый результат.

Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги:

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

Вы можете пойти дальше и использовать другие инструменты Kanban-метода: WIP-лимиты, метрики, управление потоком, каденции и т.д. Но можете этого и не делать. Решение полностью за вами. Когда будете готовы к этому, тогда и используйте.

Совместимость Kanban и Scrum

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

Все инструменты Kanban-метода можно применять при работе по Scrum: сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд. Это может быть очень полезно, так как даст Scrum-команде больше возможностей чтобы делать свою работу лучше.

Примеры применимости Scrum и Kanban

Малая команда

Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. Scrum в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.

Канбан-метод будет работать даже для одного человека. Есть понятие «Персональный Канбан», когда, вы ведете свои каждодневные рабочие дела на персональной Канбан-доске. Вам всегда видно, что у вас находится в работе, по каким задачам есть вопросы и блокеры, что в какой стадии завершенности, на что следует обратить внимание.

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

Чисто операционная деятельность

Другой пример, когда нет смысла пытаться применять Scrum — работа операторов call-центра. Потому что Scrum предполагает эксперименты, исследование и терпимость к ошибкам, а работа операторов, как правило, заключается в точном следовании “скрипту” ответов на звонки, с правильной маршрутизацией запроса звонящего. В этой ситуации Scrum ничего не даст, так как все поведение заранее определено и уложено в инструкции, которым просто надо следовать.

С другой стороны, можно собрать рабочую группу по улучшению этого “скрипта”, чтобы он мог охватывать нестандартные ситуации и по-прежнему приносил пользу. Тут появляется поле для исследования и экспериментов, и такая группа вполне может работать по Scrum. Такие примеры вы можете посмотреть в докладе Agile в операционном управлении.

Канбан-метод, при наличии соответствующих инструментов, можно применять и в работе операционистов call-центра. Будут определенные трудности с визуализацией потока входящих звонков, так как частота их поступления весьма велика. Но если это удастся сделать, то у менеджеров call-центра появится возможность собирать данные о статистике обработки запросов от клиентов, и увидеть:

На основе этой информации руководитель call-центра может принять управленческие решения и оптимизировать рабочий процесс.

Scrum и Канбан на масштабе крупной компании

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

Однако есть и разница.

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

Чтобы их преодолеть, приходится применять фасилитацию на большом масштабе, проводить громоздкие и дорогостоящие встречи (например, Big Room Planning), ради того, чтобы все вовлеченные Scrum-команды успели поговорить, спланировать свою совместную работу и двигаться дальше с общим пониманием целей, задач и контекста.

Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе совместного движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение.

В Large-Scale Scrum (LeSS) кросс-функциональные и кросс-компонентные фиче-команды (feature teams) совместно работают над общим бэклогом продукта, у которого есть один владелец продукта.

Канбан-метод рассматривает все как сервис и поток задач, о котором мы собираем данные, анализируем и принимаем решения. Поэтому на большом масштабе главная задача Канбан-метода — сделать простым сбор данных на всем протяжении производственной цепочки (от момента зарождения идеи в голове бизнеса до момента продажи и поставки продукта клиенту). А это может быть очень длинный путь, который, скорее всего, включает в себя множество отделов, департаментов, подразделений.

Если попытаться “запихнуть” работы всех этих подразделений в одну Канбан-доску и проводить возле нее Канбан-встречи со всеми вовлеченными людьми, то получится сложная и дорогостоящая встреча. Поэтому придумывают разные варианты визуализации потока задач “по частям”, с обязательными встречами по синхронизации между этими частями.

На рисунке показаны разные типы встреч, которые могут присутствовать в Канбан-методе.

Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).

Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев

С другой стороны, на разных уровнях иерархии надо собирать разные данные.

На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.

На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.

Чтобы связать данные по всем этим уровням между собой, придется создавать иерархию Канбан-досок, которые будут связаны между собой по вертикали, от стратегического уровня до тактического и обратно. Чтобы обеспечить синхронный сбор данных, прозрачность и актуальное состояние Канбан-досок на каждом уровне, нужно будет проводить координационные встречи не только “по горизонтали”, но и “по вертикали”.

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

Заключение

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

По данным исследования Agile в России

Укажите размер своей организации и узнайте, какие результаты у вас наиболее вероятны при использовании Scrum или Kanban.

Источник