в чем ключевая разница между scrum и kanban

Разбираемся в Scrum и Kanban

Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.

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

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

Обе технологии близки, потому их инструменты можно комбинировать.

Команды в Kanban и Scrum

Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.

Поскольку команда автономная и самоорганизующаяся, за успех или неудачу она отвечает как единое целое. Провал не свалить на ленивого разработчика или невнимательного тестировщика.

Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.

А вот дальше в Kanban и Scrum начинаются различия.

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

При этом универсальные команды не запрещены.

В Kanban внутри команды нет ролей.

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

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

В scrum-команде помимо собственно специалистов есть две роли.

Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:

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

Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.

Как составляют список задач

Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.

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

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

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

Как работают над проектом

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

Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.

Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.

Спринт состоит из четырех последовательных этапов.

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

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

По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.

Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.

Вспомним этапы scrum-спринта:

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

Поскольку выраженных спринтов нет, появляются особенности:

Что за доски используют Scrum и Kanban

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

Доску используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.

Доску расчерчивают на столбцы. Каждый столбец — это состояние задачи («Разработка», «Тестирование», «Релиз»). Количество столбцов зависит от проекта, но чем их меньше, тем лучше.

Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.

Доски бывают физические и электронные.

Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.

Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.

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

Я люблю настоящие доски, но без электронных иногда не обойтись.

Источник

Сравнение 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.

Источник

Kanban против scrum

Раскройте ключевые моменты при выборе между scrum или kanban, и что делать, если вы не можете решить.

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

ТВИИТ:

Не спрашивайте: «kanban против scrum». Вместо этого спросите «kanban или scrum» или даже «kanban и scrum». Используйте больше принципов, чем практики.

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

Scrum

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

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

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

Время управления, время цикла, WIP

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

Изменения могут произойти в любое время

Scrum: структурированный Agile подход

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

Ритм Scrum

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

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

Методология релиза

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

Scrum роли

Scrum имеет три четко определенные роли.

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

Ключевые метрики

Изменение философии

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

Для получения дополнительной информации о методологиях Scrum см. Что такое Scrum?

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

Kanban помогает визуализировать вашу работу, лимитирует работу в процессе выполнения (WIP) и быстро переводит работу с «Выполнение» на «Готово».

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

Ритм Kanban

Kanban основан на непрерывной структуре рабочего процесса, которая позволяет командам быть гибкими и готовыми адаптироваться к меняющимся приоритетам. Рабочие элементы, представленные в виде карточек, организованы на доске kanban, где они переходят от одного этапа рабочего процесса (столбца) к следующему.

Распространенными этапами рабочего процесса являются «Выполнение», «Выполняется», «Рассматривается», «Заблокировано» и «Готово». Но это скучно.

Методология релиза

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

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

Роли Kanban

Ключевые метрики

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

Изменение философии

Рабочий процесс kanban может измениться в любое время. Новые рабочие элементы могут быть добавлены в список необходимых требований (backlog), а существующие карточки могут быть заблокированы или удалены все в зависимости от приоритетов. Кроме того, в случае изменения способностей команды можно повторно откалибровать лимит WIP и соответствующим образом настроить рабочие элементы. Это все о гибкости (flexible) в kanban.

Для получения дополнительной информации о методологиях kanban см. Что такое kanban?

Scrum инструменты против kanban инструментов

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

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

Kanban против Scrum: Что делать, если вы не можете выбрать?

Scrum и kanban являются «гибкими (Agile ) по книгам». Они работают в проверенной и истинной манере, с которой, честно говоря, трудно спорить. Заимствуя из другой знаменитой ключевой фразы, вы можете сказать, что «никто не становится уволенным за выбор scrum».

Но ваше решение не должно быть таким черным и белым. Сотни команд используют гибридные модели, на которые влияют как scrum так и kanban. Мы решили помочь командам сделать это в программном обеспечении Jira и недавно выпустили проекты следующего поколения.

Проекты следующего поколения позволяют командам выбирать Agile функции, которые имеют для них смысл; будь то scrum, kanban или смесь того и другого. Вместо реализации одного подхода в первый день, проекты следующего поколения позволяют постепенно использовать все более и более мощные функции по мере того, как вы узнаете, что работает для вашей команды (а что нет).

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

Источник