Канбан (разработка) - Kanban (development)

Канбан ( яп .看板, что означает вывеска или рекламный щит ) - это экономичный метод управления и улучшения работы в человеческих системах . Этот подход направлен на управление работой путем уравновешивания требований с доступной мощностью и улучшения обработки узких мест на уровне системы .

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

В интеллектуальной работе и при разработке программного обеспечения цель состоит в том, чтобы предоставить визуальную систему управления процессами, которая помогает принимать решения о том, что, когда и сколько производить. Основополагающий метод Канбан возник в бережливом производстве , вдохновленном производственной системой Toyota . Он берет свое начало в конце 1940-х годов, когда автомобильная компания Toyota внедрила производственную систему под названием «точно в срок»; целью которого было производство в соответствии со спросом клиентов и выявление возможной нехватки материалов на производственной линии. Но именно инженер Microsoft Дэвид Дж. Андерсон понял, как этот метод, разработанный Toyota, может стать процессом, применимым к любому типу компании, нуждающейся в организации. Канбан обычно используется при разработке программного обеспечения в сочетании с другими методами и фреймворками, такими как Scrum .

Развитие и документирование метода

В книге Дэвида Андерсона 2010 года, Канбан , описывается эволюция подхода от проекта 2004 года в Microsoft с использованием подхода теории ограничений и включения барабан-буфер-веревка (сопоставимая с системой вытягивания канбан ) к проекту 2006–2007 годов. в Corbis, в котором был идентифицирован метод канбан. В 2009 году Дон Рейнертсен опубликовал книгу о бережливой разработке продуктов второго поколения, в которой описывается внедрение системы канбан и использование сбора данных и экономической модели для принятия управленческих решений. Еще один ранний вклад был сделан Кори Ладасом, чья книга 2008 года Scrumban предположила, что канбан может улучшить Scrum для разработки программного обеспечения. Ладас рассматривал Scrumban как переход от Scrum к Kanban. Джим Бенсон и Тониана ДеМария Барри опубликовали Personal Kanban , применяя Kanban к отдельным лицам и небольшим командам, в 2011 году. В своей работе Kanban from the Inside (2014) Майк Берроуз объяснил принципы, методы и основные ценности канбана и связал их с более ранними теориями и моделями. В своей работе « Agile Project Management with Kanban» (2015) Эрик Брехнер дает обзор практического применения Kanban в Microsoft и Xbox . Kanban Change Leadership (2015) Клауса Леопольда и Зигфрида Кальтенекера объяснили метод с точки зрения управления изменениями и предоставили руководство по инициативам по изменениям. В 2016 году Lean Kanban University Press опубликовало краткое руководство по методу, в которое были включены улучшения и дополнения из ранних проектов канбан.

Канбан-доски

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

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

Доска Канбана на диаграмме выше выделяет первые три основные практики Канбана.

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

Управление рабочим процессом

Канбан управляет рабочим процессом прямо на доске Канбан. Ограничения WIP для этапов разработки обеспечивают немедленную обратную связь между командами разработчиков по общим вопросам рабочего процесса.

Например, на доске Канбан, показанной выше, шаг «Развертывание» имеет ограничение незавершенной работы, равное пяти, и в настоящее время на этом шаге показано пять эпиков. Никакие другие рабочие элементы не могут быть переданы в развертывание, пока один или несколько эпиков не завершат этот шаг (переход в «Доставлено»). Это предотвращает перегрузку этапа «Развертывание». Члены команды, работающие над «Принятием функций» (предыдущий шаг), могут застрять, потому что не могут развернуть новые эпики. Они могут сразу увидеть почему на доске и помочь с текущими эпическими развертываниями.

После доставки пяти эпиков на этапе «Развертывание» два эпика из подколонки «Готово» в «Принятие функций» (предыдущий шаг) можно переместить в столбец «Развертывание». Когда эти два эпоса будут доставлены, никакие другие эпики не могут быть развернуты (при условии, что не будут готовы новые эпики). Теперь члены команды, работающие над развертыванием, застряли. Они сразу поймут почему и помогут с принятием функции.

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

Канбан-метрики

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

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

Время выполнения и цикл

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

Эффективные гибкие метрики используют время цикла, чтобы лучше предсказать, когда каждый элемент проекта будет завершен. Созданные Даниэлем С. Ваканти в 2015 году, действенные метрики Agile измеряют, сколько времени потребовалось для выполнения 50%, 85% и 95% задач. И используйте эту информацию, чтобы помочь команде лучше прогнозировать и контролировать сроки выполнения задач.

Смотрите также

использованная литература

дальнейшее чтение

Канбан: успешные эволюционные изменения для вашего технологического бизнеса, Дэвид Дж. Андерсон. (США, Blue Hole Press, 2010. ISBN 978-0984521401
Scrumban: Essays on Kanban Systems for Lean Software Development, Кори Ладас. (США, Modus Cooperandi Press, 2009. ISBN 9780578002149
Гибкое управление проектами с помощью Kanban (лучшие практики разработчиков) , Эрик Брехнер. (США: Microsoft Press, 2015). ISBN 978-0735698956 .
Канбан в действии , Маркус Хаммарберг и Йоаким Сунден. (Остров Шелтер, Нью-Йорк: Manning Publications, 2014). ISBN 978-1-617291-05-0 .
Экономьте из окопов: управление крупномасштабными проектами с помощью Kanban, Хенрик Книберг. (Даллас, Техас: Программисты-прагматики, 2012 г.). ISBN 978-1-93435-685-2 .
Прекратите запускать, приступайте к завершению! Арне Рок и Клаудия Лещик. (США: Lean-Kanban University, 2012). ISBN 978-0985305161 .
Канбан в реальном мире: делай меньше, добивайся большего с помощью рационального мышления , Маттиас Скарин. (США: Pragmatic Bookshelf, 2015). ISBN 978-1680500776 .

Languages

In other projects