Отличие kanban от scrum: Разбираемся в Scrum и Kanban

Различия и сходства между методологиями Kanban и Scrum

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

Канбан и Скрам — сходства

Сходство между Kanban и Scrum:

• Оба являются Agile.
• Оба используют планирование вытягивания.
• Оба ограничивают WIP, Kanban на уровне задач и Scrum на уровне спринта.
• Обе используют прозрачность в процессе разработки.
• Оба сосредоточены на выпуске освобождаемого программного обеспечения на раннем этапе.
• Оба основаны на самоорганизующихся командах.
• Оба требуют разбить работу на части.
• В обоих методах план выпуска постоянно оптимизируется на основе эмпирических данных (Scrum — Velocity, Kanban — Lead Time / Cycle Time).

Канбан и Скрам — отличия

Различия между Kanban и Scrum заключаются в следующем:

Kanban vs. Scrum

Следующие преимущества могут помочь вам выбрать между Kanban и Scrum:

• Вам нужно выбрать Kanban, если у вас уже есть рабочие процессы, и вы хотите улучшить, не нарушая всю систему, тогда как вам нужно выбрать Scrum, если вы хотите внедрить новый процесс в организации.
• Вы можете использовать Kanban в разработке продукта с Feature Driven Development для отслеживания рабочих потоков в потоке создания ценности, тогда как Scrum можно использовать для разработки на каждой итерации.
• Вам нужно определить границы WIP в Kanban явно, тогда как вам нужно определить длину спринта в схватке, которая подразумевает ограничения WIP.
• И Kanban и Scrum адаптивны, но Scrum более предписывающий, чем Kanban.
• Канбан накладывает только два правила: визуализировать рабочий процесс и ограничивать WIP, тогда как Scrum накладывает больше ограничений, таких как спринты с отложенными по времени спринтами.
• Канбан ведет к совершенствованию организационного процесса, как в области управления, так и развития. Kanban также поддерживает операции по техническому обслуживанию. Scrum приводит к высокой пропускной способности в небольших командах разработчиков. Это не способствует развитию рабочих процессов разработки и сопровождения, которые более продолжительны с непредсказуемостью по размеру рабочих единиц и изменениями. Scrum не делает акцент на оптимизации управленческой деятельности.
• В Kanban вы можете выбрать, когда делать планирование, улучшение процесса и выпуск. Вы можете выполнять эти действия регулярно или по требованию. Итерация Scrum — это один единственный спринт Sprint, объединяющий три различных вида деятельности: планирование, улучшение процесса и выпуск (если требуется).

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

Адаптация Kanban и Scrum вместе

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

Agile фреймворки: Scrum vs Kanban

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

Что же такое Agile?

Agile — это методология “гибкой” разработки ПО. И, хотя это направление появилось в ИТ сфере, оно удачно применяется и в любой другой. Сейчас различные фреймворки и подходы Agile успешно прижились в таких корпорациях, как Microsoft, Salesforce, Trenches, Hewlett-Packard, Spotify, причем не только в сфере ИТ, но еще и в сфере маркетинга и управления. Это итеративный подход, суть которого отражается в Agile манифесте, и ее можно описать следующими тезисами:

• Вся работа над проектом разделяется на короткие циклы (итерации) и ведется поэтапно;
• В конце каждой итерации заказчик получает готовый минимально работающий продукт или его часть, которую уже можно использовать;
• В течение всего рабочего процесса команда сотрудничает с заказчиком;
• Любые изменения в проекте приветствуются и быстро интегрируются в работу.

В отличие от других подходов вроде Waterfall, где можно выполнять задачи только если они были запланированы ранее, с Agile команда сможет легко подстраиваться  под новые требования и факторы. Особенно это актуально для крупных проектов, где стейкхолдеры постоянно хотят что-то поменять. 

Так выглядят аджайл спринты

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

Scrum

Термин Scrum пришел из регби. Он означает особую фигуру, в которую собираются игроки  перед началом матча, и выглядит это примерно так:

Фигура Scrum в регби

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

Суть данного фреймворка в том, что вся работа делится на спринты — промежутки времени от 1 до 3 недель. Как только спринт выполняется, происходит его ревью — оценка и анализ проделанной работы, чтобы понять, что можно улучшить. В Scrum задачи необходимо оценивать в Story points или в часах. Без этой оценки у вас не получится сформировать спринт, ведь нужно знать, сколько часов потребуется на выполнение той или иной задачи. Еще один параметр — Velocity, то есть производительность команды за один спринт. Таким образом, Scrum подойдет для объемных проектов со строгим дедлайнами, где всю работу можно распланировать по четким спринтам, зная, сколько времени тратится на выполнение задачи и получая ценную статистику, благодаря которой можно предвидеть, где команда будет через 2 недели. 

Kanban

Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски. 

Визуализация задач в канбане

Kanban визуализирует весь рабочий процесс и позволяет разделить все текущие задачи на 3 основных этапа: “Сделать”, “В процессе”, и “Сделано”. Еще один важный нюанс — Limit Work in Progress (WIP), то есть обычно ограничивается количество задач, которые сейчас находятся в процессе. Лучше синица в руках, чем журавль в небе, и стабильное выполнение небольшого количество задач лучше, чем если браться за множество тасков и толком не закончить и одного. 

Независимо от количества задач, сначала будут выполняться таски с наивысшим приоритетом. В Kanban также не проводится оценка, и нет такого понятия, как “скорость работы команды”, можно просчитать только среднее время на задачу с помощью специального отчета Cycle Time. Если в Scrum цель команды — закончить спринт, то в Kanban — задачу. 

Пример утреннего митапа

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

Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды. 

Kanban против scrum | JIRA

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

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

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

ТВИИТ:

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

Итак, где мы были?

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

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

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

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»

Методы управления проектами: Scrum vs Kanban

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

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

Гибкие или agile-методы (в переводе с английского «проворный, быстрый, подвижный») – это комплекс подходов к разработке различных продуктов (прежде всего программных), которые используют итерации (повторение определенных циклов работы), формируют требования в динамике и получают реализацию за счет постоянного взаимодействия специалистов различного профиля внутри команды.

Основная цель гибких методов – сведение к минимуму рисков за счет деления работы на итерации (длительность от 1 недели до месяца). Каждая из них представляет собой проект в миниатюре. К концу итерации он должен быть готов к выпуску. Также при завершении очередного временного отрезка команда проводит переоценку приоритетов разработки.

Agile-методы делятся на различные подходы: Scrum, FDD, экстремальное программирование, Kanban, DSDM. Сегодня сравним наиболее популярные из них – Scrum и Kanban.

Что такое Scrum?

Scrum (в переводе с английского «схватка») – свод правил, на которых строится весь процесс работы. В 1986 году впервые о таком подходе было рассказано Хиротака Такэути и Икудзиро Нонака. Они опубликовали его в Harvard Business Review (Гарвардском бизнес-обзоре). Дальше направление дополнили и внедрили в работу Джеф Сазерленд и Кен Швабер.

Основные принципы Scrum

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

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

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

• Важные термины. Резерв проекта – перечень требований к функциональности объекта разработки. Резерв спринта – список функциональных возможностей из резерва проекта, необходимых заказчику. Пункты расставлены в зависимости от важности.  

• В процессе разработки определяются роли: Product Owner, ScrumMaster и Scrum-команда. Первый отвечает за интересы заказчиков. Второй проводит встречи для обсуждения, отслеживает соблюдение установленных принципов и параметров работы и решает возникающие вопросы и противоречия. Группа квалифицированных специалистов выполняет задачи проекта.

                                            ​

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

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

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

Что такое Kanban?

Kanban (в переводе с японского kan – «видимый, визуальный», ban – «карточка, доска»). Впервые этот термин применил и описал Тайити Оно в своей книге «Производственная система Тойоты», 1953 год. Основа подхода – снижение количества выполняемых в данный момент задач.

Основные принципы Kanban

• Определение этапов работы. Их изображают в виде столбцов на доске (электронной или реальной). Задачи представляются карточками, которые перемещаются по этапам. После прохождения каждого из них мы получаем готовый к поставке заказчику элемент продукта или целый продукт.

• Отсутствие деления процесса выполнения задач по времени (нет спринтов). То есть каждый участник команды просто выполняет задачу из общего пула, работает над ней с самого начала и до завершения. Процесс считается выполненным, задача готова.

• Количество задач уменьшается за счет увеличения числа пунктов в каждой из них.

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

• Непрерывный поток. Задачи попадают в очередь в порядке приоритета. Поэтому работа никогда не прекращается.

                                             
Главная задача Kanban – это уменьшение времени прохождения задачи от начала до стадии готовности.

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

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

Вместо итогов: сравнение подходов

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

Метрики в Scrum и Kanban / Хабр

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
• Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

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

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

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

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?

в чем суть и как это работает

Agile, Scrum, Kanban – в последние годы эти термины переживают пик популярности, (по крайней мере в украинском социуме). Все больше людей стало интересоваться гибкими методологиями управления проектами и их особенностями. И это неудивительно, ведь по ним можно эффективно работать в любой отрасли, но особенно хорошо они подходят для ИТ. Но в чем суть каждой? И чтобы вы не путались в терминах, давайте разберемся как их успешно использовать.

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile.  Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.  

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-п

Использование Waterfall, Scrum и Kanban на примере одного кейса

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

Основные особенности Waterfall

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

1. Анализ требований
2. Проектирование
3. Разработка
4. Тестирование и отладка
5. Инсталляция
6. Поддержка

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

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

Scrum и Kanban. Основные различия

В отличие от Waterfall, методологии Scrum и Kanban имеют много общего:

• обе следуют принципам Бережливой (Lean) и Гибкой (Agile) разработки
• обе используют вытягивающие (pull) системы планирования
• при использовании как Scrum, так и Kanban центральное место занимает минимизация используемой документации и нацеленность на коммуникацию внутри команды и непрерывное обсуждение текущего проекта. Как следствие этого — важная роль визуализации процесса разработки посредством доски с учетными карточками, каждая из которых соответствует определенной задаче
• оба подхода стремятся к ограничению работы, выполняющейся в текущий момент
• и Scrum, и Kanban ориентированы на как можно более частый релиз готового продукта

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

Подход к ограничению количества выполняемых задач

Важным для обеих методологий является практика ограничения задач, которые выполняются в текущий момент (Work In Progress, или WIP). Однако, критерии, согласно которым выбирается количество таких задач для каждой методологии разные.

Вот пример того, как может быть визуализирован процесс разработки ПО:

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

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

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

Различные подходы к организации Scrum и Kanban досок

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

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

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

Использование разных подходов на примере одного проекта

Проект: Онлайн-приложение для хранения данных

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

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

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

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

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

Пример спринта в Jira

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

Waterfall применяется в тех случаях, когда требуется реализовать какой-то важный, достаточно большой и достаточно обособленный от общего проекта функционал. Например, этот подход использовался при разработке Excel add-in для приложения. Критичными в данном случае являются четко сформулированные требования. В этом случае команда разработчиков собирает все требования, документирует их и приступает в разработке.

Заключение

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

The following two tabs change content below.

Бизнес-аналитик, менеджер проектов XB Software и Agile-евангелист. Воодушевленно занимается развитием эффективных команд, чтобы создавать продукты, которые улучшат этот мир.

Разбор Scrum и Kanban. Что выбрать? — Личный опыт на vc.ru

Scrum — быстрая разработка сырых пользовательских историй.
Канбан – медленная разработка проработанных пользовательских историй.

Айдар Султанбек

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

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

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

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

ScrumBan

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

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

Скрам

Scrum хорошо подходит в условиях неопределенности. Когда у вас или зак

.

Различия и сходства между методологиями Kanban и Scrum

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

Канбан и Скрам — сходства

Переход между Kanban и Scrum:

• Оба являются Agile.
• Оба используют планирование вытягивания.
• Оба ограничивают WIP, Kanban на уровне задач и Scrum на уровне спринта.
• Обе используйте прозрачность в процессе разработки.
• Оба установлены на выпуск программного обеспечения на раннем этапе.
• Оба основаны на самоорганизующихся командах.
• Оба требуют разбить работу на части.
• Оба методах плана выпуска постоянно оптимизируются на основе эмпирических данных (Scrum — Скорость, Канбан — Время выполнения / Время цикла).

Канбан и Скрам — отличия

Различия между Kanban и Scrum заключаются в следующем:

Канбан vs.Скрам

Следующие преимущества могут помочь вам выбрать между Kanban и Scrum:

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

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

Адаптация Kanban и Scrum вместе

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

.