| Разработка программного обеспечения |
|---|
Канбано (японский看板, вывеска или щит ) является постным методом для управления и улучшить работу через человек системы . Этот подход направлен на управление работой путем уравновешивания требований с доступной мощностью и улучшения обработки узких мест на уровне системы .
Рабочие элементы визуализируются, чтобы участники могли видеть прогресс и процесс от начала до конца - обычно с помощью доски Канбан . Работа втягивается, если позволяет мощность, а не вталкивается в процесс по запросу.
В интеллектуальной работе и при разработке программного обеспечения цель состоит в том, чтобы предоставить визуальную систему управления процессами, которая помогает принимать решения о том, что, когда и сколько производить. , Лежащий в основе Канбан метод возник в бережливого производства , [1] , который был вдохновлен производственной системы Toyota . [2]Он берет свое начало в конце 1940-х годов, когда автомобильная компания Toyota внедрила производственную систему под названием «точно в срок»; целью которого было производство в соответствии со спросом клиентов и выявление возможной нехватки материалов на производственной линии. Но именно инженер Microsoft Дэвид Дж. Андерсон понял, как этот метод, разработанный Toyota, может стать процессом, применимым к любому типу компании, нуждающейся в организации. Канбан обычно используется при разработке программного обеспечения в сочетании с другими методами и фреймворками, такими как Scrum . [3]
Развитие и документация метода [ править ]
2010 книга Дэвида Андерсона, Kanban , [4] описывает эволюцию подхода от проекта 2004 года в Microsoft [5] с использованием теории, из-ограничений подход и включения барабана-буфер-канат (сравнимый с выдвижной системой канбан ), к проекту 2006–2007 гг. в Corbis, в котором метод канбан был [ кем? ] идентифицировано. В 2009 году Дон Рейнертсен опубликовал книгу о бережливой разработке продуктов второго поколения [6].в котором описывается внедрение системы канбан и использование сбора данных и экономической модели для принятия управленческих решений. Еще один ранний вклад был сделан Кори Ладасом, чья книга 2008 года Scrumban [3] предположила, что канбан может улучшить Scrum для разработки программного обеспечения. Ладас рассматривал Scrumban как переход от Scrum к Kanban. Джим Бенсон и Tonianne DeMaria Барри опубликовал Личный Kanban , [7] применение Kanban для частных лиц и небольших команд, в 2011 г. В канбан из нутри (2014) [8] Майк Берроуз объяснил принципы, методы и основополагающие ценности канбан и связанные с их более ранние теории и модели. ВГибкое управление проектами с помощью Канбана (2015 г.), [9] Эрик Брехнер дает обзор практического использования Канбана в Microsoft и Xbox . Kanban Change Leadership (2015) Клауса Леопольда и Зигфрида Кальтенекера [10] объяснили метод с точки зрения управления изменениями и предоставили руководство по инициативам, связанным с изменениями. В 2016 году Lean Kanban University Press опубликовало краткое руководство по методу, в которое были включены улучшения и дополнения из ранних проектов канбан. [11]
Канбан-доски [ править ]
На диаграмме показан рабочий процесс разработки программного обеспечения на доске Канбан. [12] Канбан-доски, разработанные для контекста, в котором они используются, значительно различаются и могут отображать типы рабочих элементов (здесь «функции» и «истории пользователей»), столбцы, описывающие действия рабочего процесса, явные политики и дорожки (строки, пересекающие несколько столбцы, используемые здесь для группировки пользовательских историй по функциям). Цель состоит в том, чтобы сделать общий рабочий процесс и ход выполнения отдельных пунктов понятными для участников и заинтересованных сторон.
Как описано в книгах по Канбану для разработки программного обеспечения [4] [3], двумя основными практиками Канбана являются визуализация вашей работы и ограничение незавершенной работы (WIP). Четыре дополнительных общих метода Канбана, перечисленных в Essential Kanban Condensed , заключаются в том, чтобы сделать политики явными, управлять потоком, реализовать циклы обратной связи и совместно улучшать. [11]
Доска Канбана на диаграмме выше выделяет первые три основные практики Канбана.
- Он визуализирует работу команды разработчиков (особенности и пользовательские истории).
- Он фиксирует ограничения WIP для этапов разработки: значения в кружке под заголовками столбцов, которые ограничивают количество рабочих элементов на этом этапе.
- Он документирует политики, также известные как правила выполнения [9], внутри синих прямоугольников под некоторыми этапами разработки.
- Он также показывает некоторое управление потоком Канбан для этапов «Подготовка пользовательской истории», «Разработка пользовательской истории» и «Принятие функций», которые имеют подстолбцы «Выполняется» и «Готово». Предел незавершенной работы каждого шага применяется к обоим подстолбцам, не позволяя рабочим элементам перегружать поток на эти шаги или из них.
Управление рабочим процессом [ править ]
Канбан управляет рабочим процессом прямо на доске Канбан. Ограничения WIP для этапов разработки обеспечивают немедленную обратную связь между командами разработчиков по общим вопросам рабочего процесса. [4] [9]
Например, на доске Канбан, показанной выше, шаг «Развертывание» имеет ограничение незавершенной работы, равное пяти, и в настоящее время на этом шаге показано пять эпиков. Никакие другие рабочие элементы не могут быть переданы в развертывание, пока один или несколько эпиков не завершат этот шаг (переход в «Доставлено»). Это предотвращает перегрузку этапа «Развертывание». Члены команды, работающие над «Принятием функций» (предыдущий шаг), могут застрять, потому что не могут развернуть новые эпики. Они могут сразу увидеть почему на доске и помочь с текущими эпическими развертываниями.
После доставки пяти эпиков на этапе «Развертывание» два эпика из подколонки «Готово» в «Принятие функций» (предыдущий шаг) можно переместить в столбец «Развертывание». Когда эти два эпоса будут доставлены, никакие другие эпики не могут быть развернуты (при условии, что не будут готовы новые эпики). Теперь члены команды, работающие над развертыванием, застряли. Они могут сразу понять почему и помочь с принятием функции.
Этот элемент управления рабочим процессом работает одинаково для каждого шага. Проблемы очевидны и очевидны сразу, а перепланировку можно проводить постоянно. Управление работой стало возможным за счет ограничения незавершенной работы таким образом, чтобы члены команды могли видеть и отслеживать ее в любое время.
Канбан-показатели [ править ]
Канбан использует определенные метрики для измерения возможностей команды и оценки продолжительности проекта.
Скорость работы команды определяет, сколько задач команда может выполнить за определенный период времени, например за неделю или итерацию. [13] Скорость вычисляется периодически, и чтобы помочь с точностью вычисленной скорости, команды стремятся создавать задачи, похожие по размеру. Знание скорости работы команды помогает лучше предсказать, когда проект завершится.
Время выполнения и цикла определяет среднее время, необходимое для выполнения задачи. Время выполнения рассчитывается, поскольку команда получает запрос от клиента, а время цикла рассчитывается с момента начала работы группы над задачей. Время выполнения используется, чтобы понять, как долго клиент должен ждать своего продукта, а время цикла используется, чтобы понять, насколько быстро команда производит продукт. [14]
Эффективные гибкие метрики используют время цикла, чтобы лучше предсказать, когда каждый элемент проекта будет завершен. Созданные Дэниелом С. Ваканти в 2015 году [15] действенные метрики Agile измеряют, сколько времени потребовалось для выполнения 50%, 85% и 95% задач. И используйте эту информацию, чтобы помочь команде лучше прогнозировать и контролировать сроки выполнения задач.
См. Также [ править ]
- Канбан-доска
- Бережливая разработка программного обеспечения
- Список философий разработки программного обеспечения
Ссылки [ править ]
- ^ Womack, Джеймс П. (2007). Машина, изменившая мир . ISBN 978-1847370556.
- ^ Оно, Taiichi (1988). Производственная система Toyota: за рамками крупномасштабного производства . ISBN 978-0915299140.
- ^ a b c Кори, Лады (2008). Scrumban и другие статьи о системе Канбан для экономичной разработки программного обеспечения . Сиэтл, Вашингтон: Modus Cooperandi Press. ISBN 9780578002149. OCLC 654393465 .
- ^ a b c Андерсон, Дэвид Дж. (апрель 2010 г.). Канбан: успешное эволюционное изменение вашего технологического бизнеса . Blue Hole Press. ISBN 978-0-9845214-0-1.
- ^ Андерсон, Дэвид Дж .; Думитриу, Драгош (ноябрь 2005 г.). От худшего к лучшему за 9 месяцев: внедрение решения «барабан-буфер-веревка» в ИТ-отделе Microsoft (PDF) . Всемирная конференция TOC ICO, ноябрь 2005 г. США: Microsoft Corporation . Проверено 24 сентября 2020 года .
- ^ Reinertsen, Дональд (май 2009). Принципы потока разработки продукта: экономичная разработка продукта второго поколения . Издательство Селеритас. ISBN 978-1935401001.
- ^ Бенсон, Джим; ДеМария Барри, Тониан (январь 2011 г.). Персональный канбан: работа с картами, навигация по жизни . Modus Cooperandi Press. ISBN 978-1453802267.
- ^ Берроуз, Майк (2014). Канбан изнутри . Сиэтл, Вашингтон: Blue Hole Press. ISBN 978-0-9853051-9-2.
- ^ a b c Брехнер, Эрик (2015). Гибкое управление проектами с помощью Канбан . Microsoft Press. п. 160. ISBN 978-0735698956.
- ^ Леопольд, Клаус; Зигфрид, Кальтенекер (2015). Канбан-изменение лидерства . Хобокен, Нью-Джерси: Джон Уайли и сыновья. ISBN 978-1-119-01970-1.
- ^ a b Андерсон, Дэвид Дж .; Кармайкл, Энди (2016). Essential Kanban Condensed . Сиэтл, Вашингтон: Lean Kanban University Press. ISBN 978-0-9845214-2-5.
- ^ Boeg, Джаспер (февраль 2012). «Прайминг Канбан» . InfoQ . Проверено 17 февраля 2014 года .
- ^ «Что такое скорость в Agile? | Agile Alliance» . 17 декабря 2015 . Проверено 22 октября 2020 года .
- ^ «Время выполнения и цикл - Как использовать метрики Канбан» . командный дух . 15 октября 2020 . Проверено 22 октября 2020 года .
- ^ "ActionableAgile" . actionableagile.com . Проверено 22 октября 2020 года .
Дальнейшее чтение [ править ]
- Канбан: успешные эволюционные изменения для вашего технологического бизнеса, Дэвид Дж. Андерсон. (США, 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 .
