Kanban против scrum

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

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

Легко указать на различия между практиками 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 имеет три четко определенные роли.

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

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

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

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

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

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

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

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

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

ВИДЕО

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

Ритм Kanban

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

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

Лучшая часть Kanban - это создание пользовательских столбцов для работы вашей команды. Моя команда отправляет контент, поэтому наши столбцы (упрощенно) переходят от "Список необходимых требований (backlog)", к "Приоритету", к "Готовому плану", к "Написанию", "Проектированию", "Техническому обзору" и "Предоставлению". Наша доска помогла нам узнать, что мы отправляем около одного контента в неделю, и где есть наши узкие места (глядя на вас Технический обзор!).

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

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

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

Роли Kanban

Вся команда владеет доской kanban. Некоторые команды привлекают Agile тренера, но, в отличие от scrum, не существует ни одного «мастера kanban», который бы поддерживал все в порядке. Коллективная ответственность всей команды - сотрудничать и выполнять задачи на доске.

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

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

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

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

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

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

Независимо от того, что вы выберете, придерживайтесь его некоторое время. Возьмите всю работу сделанную из списка необходимых требований (backlog), сделанную полностью, а затем спросите свою команду, что прошло хорошо, а что - плохо. Пробуя scrum и kanban и задавая эти вопросы, вы на пути к гибкому (Agile ) блаженству.

По материалам Agile Coach "Kanban vs. Scrum"