Обзор

Что такое kanban?

Kanban - это популярная структура, используемая для Agile (гибкой) разработки программного обеспечения. Требуется обмен информацией в режиме реального времени и полная прозрачность работы. Рабочие элементы представлены на доске kanban визуально, что позволяет членам команды в любое время видеть состояние каждой части работы.

ВИДЕО

Kanban чрезвычайно популярен среди современных Agile групп разработчиков программного обеспечения, но методология работы с kanban насчитывает более 50 лет. В конце 1940-х годов Toyota начала оптимизировать свои инженерные процессы на основе той же модели, которую супермаркеты использовали для складирования товара на своих полках.

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

Когда Toyota применила эту же систему к своим заводским цехам, цель состояла в том, чтобы лучше согласовать свои огромные уровни запасов с фактическим потреблением материалов. Чтобы сообщать уровни производительности в режиме реального времени на производственном предприятии (и поставщикам), рабочие передавали карточку, или «kanban», между командами.

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

 

Канбан для программных команд

Команды Agile разработки программного обеспечения сегодня могут использовать те же принципы JIT, сопоставляя объем незавершенного производства (WIP -work in progress) с возможностями команды. Это дает командам более гибкие возможности планирования, более быстрый результат, более четкую направленность и прозрачность на протяжении всего цикла разработки.

 

В то время как основные принципы этой структуры не зависят от времени и применимы практически к любой отрасли, команды разработчиков программного обеспечения добились особого успеха в этой Agile практике. Частично это происходит потому, что команды разработчиков могут начать практиковать практически без накладных расходов, как только они поймут основные принципы. В отличие от реализации kanban на заводском цехе, который будет включать изменения в физических процессах и добавление существенных материалов, единственные физические вещи, которые нужны командам программного обеспечения, - это доска и карточки, и даже они могут быть виртуальными.

Kanban доски

Работа всех kanban команд вращается вокруг доски kanban, инструмента, используемого для визуализации работы и оптимизации потока работы в команде. В то время как физические доски популярны среди некоторых команд, виртуальные доски являются важнейшей функцией любого инструмента Agile разработки программного обеспечения, из-за их прослеживаемости, облегчения совместной работы и доступности из разных мест.

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

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

 

Kanban карты

С японского языка kanban буквально переводится как «визуальный сигнал». Для команд kanban каждый рабочий элемент представлен отдельной карточкой на доске.

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

Преимущества Kanban

Kanban - одна из самых популярных методологий разработки программного обеспечения, применяемых сегодня гибкими (Agile ) командами. Kanban предлагает несколько дополнительных преимуществ для планирования задач и пропускной способности для команд всех размеров.

Гибкость планирования

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

Укороченные временные циклы

Время цикла является ключевым показателем для команд kanban. Время цикла - это количество времени, которое требуется единице работы для прохождения рабочего процесса команды - с момента начала работы до момента ее отгрузки (предоставления). Оптимизируя время цикла, команда может уверенно прогнозировать выполнение будущей работы.

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

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

Меньше узких мест

Многозадачность убивает эффективность. Чем больше рабочих элементов в работе в любой момент времени, тем больше переключение контекста, что препятствует их завершению. Вот почему ключевым принципом kanban является ограничение объема работы в прогрессе (продвижении) (WIP). Работа в прогрессе (продвижении) ограничивает узкие места и резервные копии в процессе работы команды из-за нехватки внимания (сосредоточения), людей или наборов навыков.

Например, типичная команда разработчиков программного обеспечения может иметь четыре состояния рабочего процесса: «Сделать», «В процессе», «Ревью кода» и «Готово». Они могут установить ограничение WIP 2 для состояния ревью кода. Это может показаться низким ограничением, но для этого есть веская причина: разработчики часто предпочитают писать новый код, а не тратить время на просмотр чужой работы. Низкое ограничение побуждает команду уделять особое внимание задачам в состоянии проверки и проверять работу других, прежде чем поднимать свои собственные ревью кода. Это в конечном итоге уменьшает общее время цикла.

Визуальные показатели (метрики)

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

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

 

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

 

 

Непрерывное предоставление (доставка)

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

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

Scrum против kanban

Kanban и scrum разделяют одни и те же понятия, но имеют очень разные подходы. Их не следует путать друг с другом.

 

	Scrum	Kanban
Ритм	Регулярные спринты с фиксированной длиной (например, 2 недели)	Непрерывный поток
Методология релиза	В конце каждого спринта, если одобрено владельцем продукта	Непрерывное предоставление или по усмотрению команды
Роли	Владелец продукта, Scrum Master, команда разработчиков	Нет существующих ролей. Некоторые команды заручаются поддержкой Agile тренера.
Ключевые метрики	Скорость	Время цикла
Изменение философии	Команды должны стремиться не вносить изменения в прогноз спринта во время спринта. Это ставит под угрозу обучение вокруг оценки.	Изменения могут возникнуть в любое время

Некоторые команды смешивают идеалы kanban и scrum в «скрамбан». Они берут спринты и роли фиксированной длины от scrum и сосредотачиваются на лимитах выполняемой работы и времени цикла от kanban. Однако для команд, которые только начинают работать с Agile , мы настоятельно рекомендуем выбрать одну или другую методологию и поработать с ней некоторое время. Вы всегда можете получить представление об этом позже.

По материалам Agile Coach "What is kanban?"