Войти
A Доска канбан Канбан (японский 看板, вывеска или рекламный щит ) это метод бережливого производства для управления и улучшения работы в человеческих системах. Этот подход направлен на управление работой путем уравновешивания требований с доступной мощностью и улучшения обработки узких мест.
на уровне системы.
Рабочие элементы визуализируются, чтобы дать участникам представление о прогрессе и процессе от начала до конца - обычно через Канбан-доска. Работа извлекается, если позволяет мощность, а не вталкивается в процесс по запросу.
В работе со знаниями и в разработке программного обеспечения цель состоит в том, чтобы предоставить визуальную систему управления процессами, которая помогает принимать решения о том, что, когда и сколько производить. Основополагающий метод Канбан возник в бережливом производстве, который был вдохновлен производственной системой Toyota. Канбан обычно используется при разработке программного обеспечения в сочетании с другими методами и средами, такими как Scrum.
Книга Дэвида Андерсона 2010 г., Канбан, описывает эволюцию подхода из проекта 2004 г. Microsoft использует подход теории ограничений и включает барабан-буфер-веревку (сравнимую с системой вытягивания канбан ) в проект 2006–2007 гг. в Corbis, в котором был идентифицирован метод канбана. В 2009 году Дон Рейнертсен опубликовал книгу о бережливой разработке продуктов второго поколения, в которой описывается внедрение системы канбан и использование сбора данных и экономической модели для принятия управленческих решений. Еще один ранний вклад был сделан Кори Ладасом, чья книга 2008 года Scrumban предположила, что канбан может улучшить Scrum для разработки программного обеспечения. Ладас рассматривал Scrumban как переход от Scrum к Kanban. Джим Бенсон и Тониана ДеМария Барри опубликовали Personal Kanban, применяя Kanban к отдельным лицам и небольшим командам, в 2011 году. В своей работе Kanban from the Inside (2014) Майк Берроуз объяснил принципы, практики и основные ценности канбана и связал их с более ранними теориями и моделями. В книге «Гибкое управление проектами с использованием канбана» (2015 г.) Эрик Брехнер дает обзор практического использования канбана в Microsoft и Xbox. Kanban Change Leadership (2015) Клауса Леопольда и Зигфрида Калтенекера объяснили метод с точки зрения управления изменениями и предоставили руководство по инициативам по изменениям. В 2016 году издательство Lean Kanban University Press опубликовало сжатое руководство по методу, включающее улучшения и расширения из ранних проектов канбан.
На диаграмме показан рабочий процесс разработки программного обеспечения на канбан-доске. Канбан-доски, разработанные для контекста, в котором они используются, значительно различаются и могут отображать типы рабочих элементов (здесь «функции» и «истории пользователей»), столбцы, описывающие действия рабочего процесса, явные политики и дорожки (строки, пересекающие несколько столбцов, используемые для группировки пользовательских историй по функциям здесь). Цель состоит в том, чтобы сделать общий рабочий процесс и ход выполнения отдельных пунктов понятными для участников и заинтересованных сторон.
Как описано в книгах по Канбану для разработки программного обеспечения, двумя основными практиками Канбана являются визуализация вашей работы и ограничение незавершенной работы (WIP). Четыре дополнительных общих метода канбана, перечисленных в Essential Kanban Condensed, заключаются в том, чтобы сделать политики явными, управлять потоком, реализовать циклы обратной связи и совместно улучшать.
Доска Канбан на диаграмме выше выделяет первые три общие практики Канбана.
Канбан управляет рабочим процессом непосредственно на доске Канбан. Ограничения WIP для этапов разработки обеспечивают немедленную обратную связь между командами разработчиков по общим проблемам рабочего процесса.
Например, на показанной выше доске Канбан этап «Развертывание» имеет ограничение WIP, равное пяти (5), и в настоящее время существует на этом этапе показаны пять эпосов. Никакие другие рабочие элементы не могут перейти в развертывание, пока один или несколько эпиков не завершат этот шаг (переход в «Доставлено»). Это предотвращает перегрузку этапа «Развертывание». Члены команды, работающие над «Принятием функций» (предыдущий шаг), могут застрять, потому что не могут развернуть новые эпики. Они могут сразу увидеть почему на доске и помочь с текущими эпическими развертываниями.
После того, как пять эпиков на этапе «Развертывание» доставлены, два эпика из подколонки «Готово» в «Принятие функций» (предыдущий шаг) могут быть перемещены в столбец «Развертывание». Когда эти два эпоса будут доставлены, никакие другие эпики не могут быть развернуты (при условии, что не будут готовы новые эпики). Теперь члены команды, работающие над развертыванием, застряли. Они сразу поймут почему и помогут с принятием функции.
Этот элемент управления рабочим процессом работает одинаково для каждого шага. Проблемы очевидны и очевидны сразу, а перепланировку можно проводить постоянно. Управление работой стало возможным за счет ограничения незавершенной работы таким образом, чтобы члены команды могли видеть и отслеживать ее в любое время.
Канбан использует определенные метрики для измерения возможностей команды и оценки продолжительности проекта.
Скорость команды определяет, сколько задач команда может выполнить за определенный период времени, например за неделю или итерацию. Скорость вычисляется периодически, чтобы помочь командам по обеспечению точности создавать задачи аналогичного размера. Знание скорости работы команды помогает лучше предсказать, когда проект закончится.
Время опережения и цикла Время опережения и цикла определяет среднее время, необходимое для выполнения задачи. Время выполнения рассчитывается, поскольку команда получает запрос от клиента, а время цикла рассчитывается с момента начала работы группы над задачей. Время выполнения используется, чтобы понять, как долго клиент должен ждать свой продукт, а время цикла используется, чтобы понять, насколько быстро команда производит продукт.
Оперативные метрики Agile используют время цикла, чтобы лучше предсказать, когда каждый элемент проекта будет завершен. Созданные Дэниелом С. Ваканти в 2015 году действенные метрики Agile измеряют, сколько времени потребовалось для выполнения 50%, 85% и 95% задач. И используйте эту информацию, чтобы помочь команде лучше прогнозировать и контролировать сроки выполнения задач.
