Канбан – это слово переводится с японского как «вывеска» или «рекламный щит» – был разработан как система расписаний работ в автомобильной промышленности, а сейчас представляет собой одну из самых быстрорастущих областей Agile. Его легко понять, просто применять и можно внедрить практически без затрат. Большим плюсом Канбана является то, что он может быть использован как командами для полномасштабных проектов, так и индивидуумами, чтобы контролировать объемы работ.

Не считайте Канбан просто очередной ступенькой на пути к Скраму. Да, это может быть частью путешествия по Agile, но Канбан имеет свою собственную ценность. Это не дополнительная возможность или легкий путь. Это прекрасный способ начать работу над проектом по-гибкому, и у Канбана есть масса скрытых достоинств.

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

Несмотря на эти изменения, Канбан верен своей первоначальной философии; с течением времени он улучшался и адаптировался, чтобы стать надежным и гибким инструментом. Изначальная простота основополагающих принципов остается важным преимуществом, и основой Канбана является идея плавного перехода от планирования к реализации. Суть Канбана в том, чтобы добраться из точки А в точку Я.

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

Изменения происходят по обоюдному согласию, что увеличивает вероятность добровольного использования Канбана. Помните три основополагающих принципа:

1. Определитесь с постановкой задачи.

2. Выработайте последовательные этапы задачи.

3. Следуйте согласованным процессам, ролям, обязанностям и условностям.

Блистательная мысль

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

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

Попытки забивать гвозди микроскопом не приводят ни к чему хорошему. Канбан не исключение.

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

1. Визуализация рабочего процесса. Начните с представления рабочего процесса от статуса «сделать» до статуса «сделано». Многие предпочитают включить как минимум еще один дополнительный этап в эту схему: «работа в процессе». Другие стараются разбить рабочий процесс на серию процедурных, таких как план, разработка, прототип, сборка, тестирование, имплементация, помимо начального и завершающего шагов.

2. Определение рабочей нагрузки. Попытки сделать все и сразу – лучший способ потерпеть неудачу как на индивидуальном, так и на командном уровне. Канбан ограничивает количество задач, которые находятся в работе в момент времени – этот показатель также известен как «работа в процессе» (work-in-progress WiP), – чтобы добиться максимальной эффективности. На этом этапе достаточно руководствоваться здравым смыслом, и со временем вы легко сможете выработать сбалансированную оценку WiP.

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

4. Конкретизация рабочего процесса. Конкретные представления о рабочем процессе исключительно важны для объективного оценивания его успешности. При наличии коллективного понимания сути проекта гораздо легче обсуждать его непредвзято и достигать консенсуса относительно его развития. В конце каждого этапа у вас должны быть четкие критерии оценки его успешности и того, что вы будете делать следующим.

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

Канбан отлично подходит для

• введения в Agile с минимальными затратами и рисками;

• характеристики имеющихся рабочих процессов и идентификации проблем для их реализации;

• контроля над множественными и несвязанными задачами;

• ограничения количества задач для их успешной реализации;

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

В центре метода – интересный инструмент: канбан-доска. Называть такие доски «визуализированным списком дел» – слишком большое упрощение, но они могут стать хорошей отправной точкой. Доска – это графическое представление работы от статуса «делать» к статусу «сделано». Простейший вариант канбан-доски состоит из трех колонок: «Сделать», «В процессе» и «Сделанное». Такой простой формат универсален и подойдет любому проекту.

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

1. «Идеи» – сюда помещаются задачи, которые могут пойти в дальнейшую разработку, а могут и нет.

2. «Сделать» или «в процессе» – уже принятые идеи, насчет которых нужно определить, кто именно будет над ними работать.