30 дней доступа к подписке бесплатно по промокоду
LETO
Активировать
18+

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

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

В закладки
Aydar Sultanbek

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

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

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

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

ScrumBan

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

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

Scrum

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 здесь

Scrum (Sprint) Aydar Sultanbek

Kanban

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

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

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

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

Kanban доска Aydar Sultanbek

Road Map

В крупных компаниях руководство или заказчики требуют список задач на месяцы вперед. Если вы делаете продукт на внешний рынок и используете 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.

{ "author_name": "Aydar Sultanbek", "author_type": "self", "tags": [], "comments": 3, "likes": 1, "favorites": 29, "is_advertisement": false, "subsite_label": "life", "id": 137941, "is_wide": false, "is_ugc": true, "date": "Mon, 29 Jun 2020 08:00:36 +0300", "is_special": false }
18+
Отпуск начинается с кино
30 дней подписки бесплатно по промокоду
LETO
Активировать
30 дней подписки КиноПоиск HD бесплатно для новых пользователей, которые ранее не оформляли подписки сервиса КиноПоиск HD, при условии привязки банковской карты. Подписка КиноПоиск HD 99 ₽/месяц. до 31.08.2020 г., далее — автопродление 269 ₽/месяц. Условия: ya.cc/4y4UX
0
3 комментария
Популярные
По порядку
0

В статье много неточностей и не верных формулировок, начиная с того что Канбан (метод) - это Agile подход. Что изучить глубже Скрам и Канбан метод, советую посмотреть вот это видео - https://www.youtube.com/watch?v=sGvLjXSyxUM

Так как оба подхода берут вдохновлены в бережливым мышлением, то эту статью так же советую для прочтения - https://less.works/ru/less/principles/lean-thinking.html

Удачи в работе над следующими статьями!

Ответить
0

Спасибо за обратную связь! Неточность только в том, что там где я написал подход, нужно заменить на метод? 

Ответить
0

Слоган Канбан метода - the alternative path to agility. Цитирую автора метода:

https://djaa.com/kanban-the-alternative-path-to-agility
So, is Kanban Agile or not?
If we were to assess Kanban against the Agile Manifesto, we would conclude that Kanban’s deferred committment is aligned with “responding to change over following a plan” but the other three statements of the manifesto are largely orthogonal concerns to the implementation and use of the Kanban Method.

Agile (в изначальном понимании, как Agile Software Development) не включает в себя Канбан метод. Если рассматривать канбан (с маленькой буквы), как доску для визуализации, то это инструмент, который может быть использован где угодно - в Скрам команде, в Канбан методе (как одна из его практик), в МакДаке.... Везде где, требуется визуализация потока создания ценности.

Если интересно разобрать всю статью, то лучше по голосовой связи, пишите в ФБ @artem.v.krotov.

Ответить

Блоги компаний

Показать еще

Комментарии