kanban что это такое простыми словами

Методология Kanban: доски, принципы и возможности управления

Управлять командой нелегко. Особенно в digital. Нужно организовать работу так, чтобы и дедлайны соблюдались, и заказчик был доволен.

Вы когда-нибудь собирали вместе группу людей, чтобы создать продукт или запустить проект? В качестве бонусов — жёсткий дедлайн, объемное техзадание и несговорчивый заказчик. Получилось? Всему этому мы учим на курсе «Руководитель digital-проектов».

Волшебной таблетки для решения всех проблем не существует. Но есть методы, которые упрощают работу команды. Один из них ― Kanban.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.

Что такое Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Цель Kanban

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

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

Доски Kanban

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

Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел.

Как устроен Kanban в проектах

У каждого проекта есть план процесса работ. Сначала мы его анализируем и разделяем доску на столбцы, которые отражают этапы. Например, для процесса создания IT-проекта этапы могут быть такими:

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

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

C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект.

На доске отражаются все процессы. Команда их анализирует и устраняет слабые места. В Kanban это называется управлением потоком.

Чтобы использовать Kanban, одной доски недостаточно. Команда должна знать принципы, по которым работает.

Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, поэтому каждый может увидеть свой вклад и ценность для проекта.

В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жёстких правил, но есть принципы, на которые можно опираться.

Как помогает визуализация

Визуализация помогает видеть картину целиком и корректировать отдельные её части, понимая, как изменения затронут весь проект. Получить результат точно в срок возможно, если контролировать нагрузку команды. Определите количество задач: сколько команда реально способна решать в установленные сроки. Например, в «Проектировании» одновременно ― не больше двух задач, а на «Тестировании» ― только одна. Всё в зависимости от возможностей команды.

Ситуация: разработчик ещё не закончил с текущей задачей, а ему уже поступила следующая. Он не успевает и тормозит всю работу.

Решение: прекратить передавать задачи в разработку и дать программисту время закончить текущую.

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

Ситуация: на этапе тестирования продукта возникли трудности. Нужно больше времени.

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

Чем отличаются
Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Но это не совсем так.

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

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

Команда уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Как внедрить Kanban

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

Заключение

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

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

Источник

Методология Kanban: введение

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

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

Если вам не хочется читать — я сделал видео, где на пальцах описываю историю и основные принципы метода Канбан.

История термина

Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.

Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала — 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики — количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.

В упрощенном варианте, Kanban включает в себя два простых правила:

Настоящее время

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

Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Предлагаю рассмотреть пример использования Kanban в разработке программного обеспечения. Заранее прошу простить за некрасивые иллюстрации. Давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе — 1 шт.

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

Заключение

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

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

Более подробно, и наглядно можно посмотреть в:

Источник

Что такое Канбан-метод – максимально коротко

Максимально коротко о Канбан-методе, его основные термины и области применимости.

1. Что такое Канбан-метод?

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

Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

2. Канбан-метод и Канбан Тойоты – это одно и то же?

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

Давайте разберем короткий пример. Нам нужно сделать три автомобиля “точно в срок”. Это значит, что мы точно заранее можем определить, сколько нам потребуется деталей на определенных этапах, и начинаем с конца вытягивать необходимое количество деталей для создания этого автомобиля, отвечая на вопросы: “Сколько литров краски нам потребуется?”, “Сколько колес?”, “Сколько двигателей?” и так далее. Таким образом, мы не создаем излишки запасных частей в виде остатков и экономим на складах, логистике и прочих издержках.

Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.

3. Можно ли использовать Канбан-метод не в IT?

Да. Канбан-метод подходит для визуализации потока любой творческой и интеллектуальной работы. Но гораздо эффективнее использовать его через призму сервисной парадигмы. Посмотрите на то, что вы делаете, как на сервис. Через какие стадии проходит работа, чтобы сервис был оказан? По каким критериям вы поймете, что сервис оказывается в соответствии с ожиданиями Заказчика? Это отправная точка в применении Канбан-метода. Канбан-практики называют эту точку “начните с того, что есть сейчас”.

4. Канбан – это как Скрам?

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

5. У Канбана есть ценности?

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

6. Вы написали о принципах Канбана. Какие они?

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

Так как Канбан-метод живет в сервисной парадигме, он придерживается ее принципов:

7. А что за практики в Канбане?

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

8. О, каденции! Что такое каденции в Канбане?

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

9. Я что-то слышал про классы обслуживания. Что это?

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

10. Что на счет метрик? Как померять эффективность работы сервиса?

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

11. С какими проблемами сталкивается Канбан при внедрении?

Основная трудность – это объяснить людям на всех уровнях ценность практик Канбана: визуализации и ограничения незавершенной работы. Из-за того, что люди не видят объем интеллектуального труда, им сложно понять, какой нагрузке они подвергаются. А ведь мозг, к примеру, такая же мышца, как и бицепс. Представьте себе тренажерный зал: вы приходите и видите вес на штанге: “Так, это слишком мало. А сейчас – слишком много. А вот это в самый раз!” С мозгом нужно работать точно также: “Вот эта – большая задача, а эта – маленькая, да и вообще как-то много я на себя взвалил. Ограничу-ка я нагрузку”. Когда на всех уровнях мы делаем сквозную визуализацию потока работы и ограничиваем количество незавершенной работы, мы создаем вытягивающий принцип для интеллектуального труда и делаем равномерный поток его результатов для наших клиентов.

12. А какие есть программы для Канбан-метода?

Их тоже много. Перечислим только профессиональные, разработанные специально под метод. Наше сердце отдано российской разработке Kaiten. Кроме нее есть еще TargetProcess, SwiftKanban, LeanKit и другие.

13. И в каких компаниях уже используется Канбан-метод?

Среди российских это Альфа-Банк, Хоум Кредит Банк, Почта-Банк, Додо Пицца, HeadHunter, Clever и другие. Из иностранных: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Этот список можно продолжать долго.

14. Есть еще что-то важное?

Да. Напоследок хотелось бы отметить важность двух ролей в Канбан-методе. Это менеджер сервиса поставки (service delivery manager) и менеджер сервиса запросов (service request manager). Первый отвечает за устранение препятствий в потоке поставки. Второй – за управление потоком запросов к сервису от множества заказчиков. Очень важно, чтобы эти две роли были партнерами и работали в паре.

Источник

13 причин перейти на Kanban. И никаких суеверий

В процессах разработки, как и в других сферах деятельности, не всегда получается сразу «нащупать» верный путь, зачастую приходиться испытать множество терний. От выбора подходящей методологии разработки зависит будущая жизнь продукта или услуги. Мы собрали 13 преимуществ от внедрения Kanban для разработки программного обеспечения.

Что такое Kanban?

Разберем следующий пример, рассмотрев две ситуации.

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

Вторая ситуация – шоурум Toyota в наши дни. Покупатель выбирает модель и вносит оплату. Однако на складе Toyota в этот момент нет вашего цвета автомобиля. Заказ отправляется в головной офис Toyota. Вам сообщают сроки, когда машина будет доставлена. Только с этого момента автомобиль начинают производить. Специально для вас. Налицо принцип: сперва продажа, потом производство. Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.

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

Одной из ключевых составляющих JIT-принципа является Kanban. Доски и карточки Kanban – это своеобразные светофоры в системе just in time. Kanban дает возможность бизнесу быть реактивным по отношению к потребностям клиента вместо прогнозирования потребностей, как это случилось в первой описанной ситуации.

Можно спроецировать похожий пример на область разработки ПО:

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

Случается и обратная ситуация: у QA скапливается очень много задач и он/она не успевает все вовремя проверять. В этом случае, срок выпуска продукта также откладывается.

В разработке ПО сбалансировать Kanban намного сложнее, чем на производстве. Сказывается специфики работы: если станки выпускают однотипные детали, то программисты работают с кодом собственными усилиями головного мозга, в котором что-то около 100 млрд нейронов и один, но весомый человеческий фактор.

Для чего разработке ПО нужен Kanban?

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

13 причин перейти на Kanban

Вот 13 причин, по которым стоит внедрять Канбан в IT компании, которые занимаются разработкой ПО:

1.Определение узких мест

Переход на Kanban доски с обычных списков задач сразу показал нам узкое место: в колонке Testing скапливалась большая очередь задач. Наш QA не справлялся с проверкой задач. Он брал задачи на проверку с большой задержкой. После того, как тестировщик возвращал задачу на доработку, программист уже успевал ее забыть. Приходилось снова смотреть код и вспоминать детали. Как понимаете, это драгоценное время. Команде потребовался еще один тестировщик.
Kanban доска позволяет увидеть узкие места в вашем процессе, где образуются очереди. В Hygger.io c этой задачей помогают справиться WIP лимиты. Если у вас больше или меньше задач, чем нужно — колонка подсвечивается красным или желтым цветом соответственно.

2. Точный порядок выпуска фич

Часто большое значение имеет порядок выпуска фич. В списках, построенных на приоритетах, тяжело точно управлять порядком. Если у программиста будет одновременно пять задач с главным приоритетом, ему будет сложно сориентироваться, какую из этих задач взять в работу первой.
Kanban доска как раз предлагает выход из ситуации, когда порядок имеет значение. Это визуальное решение — вертикальная колонка с задачами. Чем выше задача, тем она важнее. Kanban, кстати, предполагает определение приоритетов, как один из важных аспектов методологии. Постоянно меняются требования, многие задачи могут терять актуальность и «спускаться» вниз. Какие-то таски могут наоборот резко «подняться». Менеджер должен постоянно «держать руку на пульсе», чтобы программисты выполняли самое нужное.

3. Приоритет главным задачам

Kanban учит отдавать главное внимание главным вещам. Тому, что реально добавляет ценности продукту. Мы смогли «опустить» вниз множество бесполезных багов и доработок. Это дало результат.
Отличать важные баги от менее приоритетных – непростая задача для менеджера продукта, но здесь ему на помощь приходит функция Swimlanes. Это горизонтальные колонки на Kanban доске. Как правило, у программистов на доске присутствуют такие Swimlanes:

4. Концентрация на работе

Программист должен быть сконцентрирован на своей работе. Поэтому хорошо, когда он получает очередь задач и ему не нужно думать, что делать дальше, об этом уже подумал менеджер. Просто нужно брать в работу следующую задачу или баг.
Иногда Kanban предполагает самостоятельный выбор программистами любых задач сверху. Тогда профессиональный уровень всех людей должен быть равным, чтобы не получилось, что самая сложная задача «падает» на junior специалиста.
Фильтр My Tasks помогает установить фокус на свои задачи. Он помогает быстро увидеть свои задачи на доске.

5. Панорамный вид

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

6. Гибкость

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

Чем чаще такты, тем команда разработки становится более гибкой. Для нашей команды идеальный такт составляет 8-12 часов. Крупные задачи обязательно декомпозируются.

7. Не нужно оценивать фичи

Scrum забирал много времени на оценку фич перед стартом спринта. С Kanban потребности в оценке нет. Когда сделаем, тогда и будет сделано.

8. Больше дела

Scrum предполагает много коммуникации. Начало спринта сопровождается планированием: анализом и оценкой задач. Каждую неделю обязательны стенд-апы. После окончания спринта проводится ретроспектива. По итогу, вся коммуникация отнимает около 30% времени. А ведь это время команда могла бы потратить на работу.

9. Командный дух

С Kanban команда начинает работать более согласованно. Сейчас тестировщик проверяет фичу практически сразу после того, как ее сделал программист. Аналогично и в других областях: у дизайнеров, UX, редакторов, сейлзов.

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

10. Ошибаться раньше — быстрее находить решение

В Scrum мы «заливаем» фичи на production только в конце спринта. Примерно раз в 3 недели. В Kanban — практически сразу после приемки тестировщиком. Раз в несколько дней.

Так мы быстрее узнаем, зашла фича пользователям или нет. Если нет — где-то произошла ошибка. А нам важно ошибаться первыми. Это вовсе не означает, что мы любители ошибаться. Но если мы узнаем об ошибке первыми, мы первыми будет знать и решать, что делать.

11. Больше потока

Не нужно постоянно «дергать» программистов. Открыли Kanban доску, быстро глянули кто и чем занят, все статусы, и спокойно можно вернуться к менеджменту. А программист продолжает оставаться в состоянии потока, и в предвкушении взятия новых вершин.

12. Больше знаний – лучше для проекта

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

13. Концентрация на одной задаче

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

В качестве заключения

Может показаться, что мы настаиваем на том, что Kanban лучше Scrum. Но это не так. Всему свое время. Опыт Hygger позволяет утверждать: Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.

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

Источник