Scrum kanban vs – в чем разница и что выбрать? / Блог компании Hygger / Хабр

в чем разница и что выбрать? / Блог компании Hygger / Хабр

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

Две популярные Agile-методологии

Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными. Перед тем, как разобраться в разнице между ними, вспомним кратко о том, что их объединяет.

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

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

Можно смело согласиться со всеми аргументами, ведь действительно:

• Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
• MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
• Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.

Зачастую в последнее время проект — это стартап. В контексте стартапов приходит на ум «customer development» (оригинальную методику замечательно описал Стив Бланк).

По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:

— проблемы, решением которых мы занимаемся, существует в жизни пользователя.
— эти проблемы существенные.
— пользователь будет за них платить
— есть рынок, и это не проблема одного человека.
— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).

• Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).

Это основные идеи манифеста, но есть еще знаменитые 12 принципов, которые говорят сами за себя. Так что, глубоко «копать» в них не будем, а лучше вернемся к основному вопросу отличия Scrum от Kanban.

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.

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

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

Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (вы выбрали «максималку» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.

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

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.

Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

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

Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.

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.

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

А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!

habr.com

Сравнение методологий управления проектами Kanban vs Scrum vs Agile

Kanban

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

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

Доска разделена на три логические секции: «ожидание», «работа в процессе» и «завершенная работа». Но Kanban-доска может быть организована несколько иначе, в зависимости от конкретного проекта. Секции доски могут меняться: «ожидание», «работа в процессе», «численность команды», «проверка кода», «тестируется», «результат».

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

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

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

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

Главные элементы помещаются в верхнюю часть списка «ожидание». Приоритет элементов можно изменить.

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

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

Scrum

Scrum, как и Kanban, — это еще один фреймворк для методологии Agile. В Scrum фиксированная продолжительность итераций, участникам отводятся определенные роли. Итерации называют спринтами. Каждый спринт длится от двух недель до месяца. И начинается с планирования: во время обсуждения подытоживают содержимое бэклога (журнал требований), определяют возможности ПО (в дальнейшем все остается без изменений).

Каждый спринт начинается с планирования, во время которого:

• Выбирается бэклог продукта для определенного спринта.
• Определяется масштаб и критерий завершенности элементов.
• Элементы бэклога по необходимости могут разбиваться на части.
• Составляется список требований.
• Требования к функциональности упорядочиваются по степени важности.

Ежедневные скрам-совещания

• На совещаниях присутствуют все участники команды.
• Совещания, как правило, длятся не дольше 15 минут.
• Участники команды отвечают на два вопроса: что было сделано после прошлой встречи, что будет сделано к следующей?
• Обсуждаются блокировщики, слабые места и прочее вопросы.
• В конце спринта проводятся т.н. ретроспективные совещания.
• Демонстрируется готовая работа.

Анализируются два аспекта: успешные детали спринта и то, что планируется охватить за следующий спринт.

По завершении спринта, эти же шаги повторяются для оставшихся элементов бэклога.

В скрам-методике участникам отводятся определенные роли. Их три: владелец продукта, скрам-мастер и команда разработки.

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

Скрам-мастер. Они занимаются планированием спринтов, проверками, ежедневными совещаниями и пр.

Команда разработки. Специалисты разных профилей — тестировщики, аналитики, программисты — общими усилиями занимаются анализом, дизайном, разработкой, тестированием, документированием.

Kanban Vs Scrum

В описаниях этих методик немало общего. Но на практике отличий предостаточно.

Scrum	Kanban
Продолжительность итераций/спринтов строго определена. Как правило, от двух недель до месяца.	Определяется именно продолжительность циклов.
Команда оценивает или планирует каждый спринт, исходя из информации в бэклоге.	Отслеживается рабочий процесс/рабочий элемент/Kanban-карта
В этой методике участникам отводятся три роли: владелец продукта, скрам-мастер и команда разработки.	Процесс построен без ролей.
После начала спринта изменения не допускаются.	В этом отношении Kanban более гибкая методика. Изменения вносятся в любое время.
Вся работа разбита на несколько этапов/спринтов.	Ход работы идет одним потоком.

 

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

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

Чем отличается Scrum и Agile?

Сравнивать Scrum и Agile — все равно, что сравнивать понятия «красный» и «цвет». Красный — отдельный цвет и его присутствие зависит от вкуса дизайнера и уместности в конкретных условиях. Так же и в случае с Agile и Scrum. Scrum — отдельная разновидность гибкой методологии Agile

getbug.ru

Kanban vs Scrum | AgileRussia

Стас Фомин, компания CustIS

7 июля прошло очередное собрание сообщества AgileRussia, посвященного занимательнейшей теме – сравнению методологий разработки Scrum и Kanban. И если Scrum уже начал терять ореол свежести и модности, уже накопились претензии не от тех, кто «Пастернака не читал, но осуждает», а от реально практикующих Scrum в течение пары лет, то Kanban – штука в софтверной индустрии новая, и при этом не выдуманная заумь от софтверных методологов (или даже целых Институтов Программирования), а реальная практика, пришедшая из японского автомобилестроения – индустрии, уважаемой большинством программистов, даже не ездящих на «японках».

Кстати, обычно практики приходящие в софтверный инжиниринг из реальной инженерии (строительство, машиностроение, …), отличаются тяжеловесностью, обилием сложных правил и ограничений, содержат строгую специализацию по ролям – ведь в реальном мире все это действительно оправдано, и отклонение от СНИПов и прочих строительных ГОСТов, нарушение последовательности строительных операций, и т.п. – почти гарантированно приводят к проблемам, а зачастую и к катастрофам с человеческими жертвами. В софтверной же индустрии, используемый при построении информационных систем и других сложных программ «материал» – операционные системы, библиотеки, фреймворки – не менее сложен, чем сталь или бетон, но при этом более гибок, – например, для информационной системы можно (хотя и сложно), без последствий для пользователя, полностью или частично заменить фундамент – сменить используемые библиотеки или даже архитектуру. Поэтому «классическое управление проектами», с диаграммами Ганта и безликими человеческими ресурсами плохо работает в разработке ПО, где для эффективной работы в первую очередь надо сосредоточиться на удобстве командной работы, учитывая психологию разработчика (по отдельности и в группе), минимизируя ручные операции, исключая ненужную работу, т.е. всеми возможными способами повышая мотивацию участников и исключая «узкие места» процесса. Собственно успех Agile-практик показывает, что мораль Крыловской басни «…а вы друзья, как ни садитесь…» к софверной разработке не очень применима, а вот применим скорее сюжет фантастического рассказа «Побег» (из сборника «Лавка сновидений» Ильи Варшавского), где удалось радикально поднять производительность уборки хлопка у заключенных, просто убедив их, что они свободны, и собирают «белые цветы радости».

Этим и объясняется успех Scrum-а для измученных нарзаном RUP-ом или MS Project-ом. Но с другой стороны, у многих, особенно у пришедших к Scrum-у от «методологии Бей и беги Code-and-Fix», возникает много претензий к Scrum-практикам – можно ли еще упростить? Можно ли выкинуть еще один (детский? туземный?) ритуал? …

Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP. Неудивительно, что зал нашей компании был полон ПиЭмами, интересующимися – решит ли Kanban их проблемы со Scrum? Можно отказаться от итераций, планирования и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, как часто бывает, «истина где-то посередине» – и оптимальным будет именно сочетание Scrum и Kanban?

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

Правда мы должны предупредить читателя, что перед тем как смотреть видео, лучше выполнить домашнее задание и прочитать-пролистать вводные материалы по Kanban (собственно это заранее и проделали все собравшиеся):

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

В целом, содержание видео следующее. Первая часть – вербализация проблем Scrum, которых собравшиеся надеялись решить через Kanban. Была исписана целая стена плача маркерная доска, где были и здравые надежды и претензии типа «…доктор, я смогу после операции играть на скрипке?…», а советы по лечению, под стать вопросам, отсылали даже, скажем, к сексуальным играм для взрослых.

http://vimeo.com/moogaloop.swf?clip_id=5543538&server=vimeo.com&show_title=1&show_byline=1&show_portrait=1&color=00ADEF&fullscreen=1

Кратко ключевые слова из этих проблем, ставшие «меню» этой встречи:

1. «Support Team». Техподдержка, багфиксинг, доработки.
2. «Сильно распределенная разработка». Разработчики в разных местах, их трудно синхронизовать.
3. «Сверхкроссфункциональные микрокоманды». Пара парней на все руки (см. сериал «IT Crowd»).
4. «Безудержный заказчик или нестабильный backlog»/«Несинхронизованный deployment»/«Хаотически меняющиеся приоритеты». Постоянные внезапные форс-мажорные заказы «фич» вне бэклога в текущую итерацию.
5. «Мутные красные бумажки», «Стек-вместо-очереди», «Research-and-Development».
6. «Scrum-шизофрения: Два product-ownera на одну команду».
7. «Случай-в-Питере» — Разработка «Софт-плюс-Железо», сложность синхронизации разных команд с разными технологиями.
8. «Растянутый Workflow задачи» — долгая многоитерационная постановка, или тестирование на стороне заказчика.
9. «Технологическая цепочка».
10. «Существенно разномощные задачи» — «фрагментация корзины бэклога».
11. «Проектная аритмия» (сбивается ритм демо, планирований, ретроспектив) — разный ритм участников разработки (включая заказчика).
12. «Проблема счастливой семейной жизни» — waste времени на ретроспективы.
13. «Дефицит Product Ownerов» — они могут стать критическим ресурсом.
14. «Расслабляющая команда», «Деградация через самоорганизованное командой уменьшение Scope».
15. «Трудно форсировать Аврал».

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

http://vimeo.com/moogaloop.swf?clip_id=5545293&server=vimeo.com&show_title=1&show_byline=1&show_portrait=1&color=00ADEF&fullscreen=1

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

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

Кстати, каждое видео можно скачать (в отличном качестве, с обработкой от видеошумов), если перейти на страничку видео на самом видеохостинге.

http://vimeo.com/moogaloop.swf?clip_id=5548407&server=vimeo.com&show_title=1&show_byline=1&show_portrait=1&color=00ADEF&fullscreen=1http://vimeo.com/moogaloop.swf?clip_id=5549519&server=vimeo.com&show_title=1&show_byline=1&show_portrait=1&color=00ADEF&fullscreen=1

Ну и на память – та самая доска проблем Scrum, которых пытались лечить Kanbanом.

Ну для любителей подкастов, прилагаем отдельно и аудиозапись:

http://file.podfm.ru/player.swf

agilerussia.ru