Отличие scrum от kanban

Анонимный вопрос
  · 3,8 K
Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Миша Ряженка

И Scrum, и Kanban — гибкие фреймворки менеджмента (Agile подход). При этом они фокусируются на разном, и у них разные "степени свободы".

Scrum более жесткий. У него строгие регламенты проведения мероприятий. Обязательно должны быть 3 роли, 5 мероприятий, обязательно должен быть беклог, работать нужно короткими итерациями (спринтами) и т.п.

Kanban более мягкий. В нем всего два главных "предписания" — 1) визуализация процессов и 2) сокращение WIP (Work In Progress, работы в процессе). При этом остальное остается на ваше усмотрение - например, вам не обязательно выделение мероприятий и ролей (это может быть желательно, однако Канбан напрямую этого не предписывает, в отличие от Scrum). Проще говоря — работайте как хотите (даже по Scrum), только визуализируйте процессы и не берите в работу больше задач, чем нужно.

В целом у них также разные ценности, хотя все они согласуются с ценностями Agile.

15 января  · 4,1 K
Комментировать ответ…
Вы знаете ответ на этот вопрос?
Поделитесь своим опытом и знаниями
Войти и ответить на вопрос
Читайте также

Scrum фреймворк — что такое «Скрам», руководство по методологии управления проектами?

Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Андрей

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

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

  1. Исследовать и выявлять жизнеспособные рынки, технологии и возможности продуктов;
  2. Разрабатывать продукты и улучшать их;
  3. Выпускать продукты и их обновления по несколько раз в день;
  4. Разрабатывать и поддерживать облачные технологии и другие среды для использования продуктов (онлайн, безопасно, по требованию);
  5. Поддерживать и обновлять продукты.
30 января  · 3,9 K
Прочитать ещё 1 ответ

В чем разница методологии scrum и waterfall?

Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Миша Ряженка

Waterfall это:

Планирование проекта от А до Я, после чего ведется работа. Любые изменения в запланированном не поощряются, так как это мешает всей системе.

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

Scrum это:

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

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

Подробнее про Scrum: https://leadstartup.ru/db/scrum

На картинке - графически отображено как выглядит разница.

introduce-scrum-methodology-difference-waterfall.png
16 января  · 4,7 K
Прочитать ещё 4 ответа

Что такое Kanban Maturity Model?

Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Александра

Kanban Maturity Model (KMM) — «модель зрелости канбан» — собирает и обобщает десятилетний опыт внедрения и реализации канбан в различных организациях. Авторы Kanban Maturity Model — David J Anderson и Teodora Bozheva.

Модель предназначена для отображения и понимания степени внедренности и интегрированности ценностей и практик канбан в организации.

В Kanban Maturity Model выделяются несколько «уровней зрелости»:

Уровень зрелости 0 — Очевидность ценности. Если ваша организация не знает о необходимости структурированного рабочего процесса, вы определенно на нулевом уровне зрелости.

Уровень зрелости 1 — Командная работа. На первом уровне зрелости члены команды уже выработали привычку использовать канбан на индивидуальном уровне. Они понимают, зачем нужно ограничение WIP и визуализация. Наступает время «масштабировать» преимущества канбан на командный уровень.

Уровень зрелости 2 — Повышение определенности. Пока что ваша команда поняла, что использование принципов канбан улучшает сотрудничество и обеспечивает прозрачность рабочего процесса. Следующим шагом является осознанность рабочего процесса (workflow). Другими словами, команда начинает понимать, как именно они делают вещи.

Уровень зрелости 3 — Управление процессом. По мере того, как вы начинаете перерастать уровень зрелости 2 и начинаете переход от процесса, ориентированного на клиента, к процессу ориентированному на цели клиента («Fit For Purpose»), практики правильной визуализации становятся более важными.

Уровень зрелости 4 — Управление рисками. Уровень зрелости 4 в Kanban Maturity Model характеризуется управлением рисками и принятием решений на основе данных. Здесь также есть некоторый серьезный прогресс в отношении визуализации рабочего процесса и управления потоком.

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

Уровень зрелости 6 — это когда мы можем утверждать, что бизнес действительно «построен на длительный срок».

22 мая  · 493

Где может работать Скрам (Scrum) помимо IT? И может ли?

Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Миша Ряженка

Возможные области применимости:

  • Маркетинг
  • Производство любых продуктов,
  • Творчество
  • B2G (кейсы правительств северной Европы)
  • Другие

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

Отлично работают маркетинговые скрам-команды, где целью проекта является прибыль и все действия направлены именно на ее извлечение.

Пример из музыкальной индустрии: https://www.scrum.org/resources/blog/using-scrum-music-industry

Scrum также можно успешно применять в медиа, есть кейс NPR: https://www.poynter.org/reporting-editing/2012/how-npr-benefits-from-agile-project-development-you-can-too/

Кейс с гос. управлением в США (там же есть список организаций, работающих по фреймворку):

https://appdevelopermagazine.com/how-agile-scrum-development-methodologies-work-in-the-federal-space/

16 января  · 505
Прочитать ещё 1 ответ

Каким должен быть хороший Scrum эксперт?

Готовим с нуля ТОП–менеджеров новых бизнес–направлений и IT–стартапов.  · leadstartup.ru
Отвечает
Александра

Есть как минимум четыре характеристики, которые вы точно должны искать при выборе правильного специалиста по фреймворку Scrum.

1. Твердое понимание Servant Leadership и фасилитации

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

2. Неумолимый подход к постоянному совершенствованию

Успешный Scrum эксперт — это человек, непрерывно улучшающий и оптимизирующий работу команды. Лучший способ сделать это — ретроспективный анализ процессов и процедур, что приводит к оптимизации.

3. Хорошие отношения с командой и определенная степень влияния

Настоящий эксперт в реализации Scrum должен быть в состоянии управлять уважением команды, даже если формально ему не хватает власти/влияния.

4. Широта знаний о продукте, рынке и области

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

10 июня  · 440