Весной 2005 года мне посчастливилось провести отпуск в Японии, в Токио. Дело было в начале апреля, когда цветут вишни. Чтобы насладиться этим зрелищем, я во второй раз в жизни приехал в Восточные сады в Императорском дворце в Токио. Именно здесь меня осенило: канбан – это не только производство.

В субботу, 9 апреля 2005 года, я вошел в парк с северного входа, перейдя мост через ров неподалеку от станции метро «Такэбаси». Многие токийцы решили этим солнечным воскресным утром выбраться в парк и насладиться его спокойствием и цветением японской вишни – сакуры.

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

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

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

Что же это за входные билеты? Зачем их выдавать, если они бесплатные? Сначала я предположил, что это связано с безопасностью. Подсчитав все возвращенные карточки, администрация могла убедиться, что внутри не осталось никого постороннего после закрытия парка на ночь. Однако затем я понял, что если речь идет о безопасности, то это какая-то очень сомнительная схема. Как они могут знать, что мне дали не одну карточку, а две? Моя трехмесячная дочь – это посетитель или багаж? Система казалась слишком вариативной. Чересчур много возможностей для ошибки! Если бы это действительно была схема безопасности, то она была обречена на провал и ежедневно давала бы ошибки первого рода. (Кстати, отмечу, что подобная система не может выдавать ошибки второго рода, поскольку это потребовало бы печати дополнительных входных билетов. Это общее полезное свойство систем канбан.)

Тем временем охрана ежевечерне рыскала бы по парку в поисках заблудившихся туристов. Нет, дело в чем-то другом. И я понял, что в садах Императорского дворца реализуется канбан-система! Это озарение позволило мне понять, что канбан-системы полезны не только в производстве. Похоже, канбан-жетоны разного вида помогают во всех типах управленческих ситуаций.

Некоторое количество канбан-жетонов (в нашем случае – карточек), равное (оговоренной) емкости системы, запускается в обращение. Одна карточка соответствует одному элементу работы. Каждая карточка – это сигнальный механизм. Новый элемент работы может начаться, только если для него доступна карточка. Эта доступная карточка прикрепляется к элементу работы на время его прохода через всю систему. Когда карточек больше не остается, новую работу начинать нельзя. Любая новая работа должна оставаться в очереди, пока карточка не освободится. Когда какое-то количество работы окончено, карточка освобождается и снова запускается в обращение. Теперь можно начинать работу над новым элементом в очереди.

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

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

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

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

Рис. 2.1. Стена карточек канбан (с разрешения SEP)

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

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

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

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

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

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

1. Визуализация рабочего потока.

2. Ограничение количества незавершенных задач.

3. Измерения и управление потоком.

4. Формальные политики процессов.

5. Использование моделей для оценки возможностей совершенствования.

В реализациях Канбана мы ожидаем увидеть появление новых привычек и осознания некоторых правил, список которых постоянно растет. Некоторые из них (или даже все) есть в большинстве последних реализаций. Так, все они присутствовали в Corbis за 2007 год. Мы полагаем, что этот список будет расти, когда мы больше узнаем о влиянии Канбана на организации.

• Процессы уникальны для каждого проекта или потока создания ценности.

• Разделенные каденции (или разработка, не привязанная к единому итерационному циклу).

• Рабочее расписание определяется стоимостью задержки.

• Оптимизация поставки ценности с помощью классов обслуживания.

• Управление рисками основывается на емкости производственной системы.

• Терпимость к экспериментам в процессе.

• Управление на основании количественных показателей

• Вирусное распространение (Канбана) по организации.

• Слияние небольших команд для создания единых трудовых центров.

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

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

В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах» и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia».

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

В 2007 году несколько человек побывали в моем офисе в Corbis, чтобы посмотреть на Канбан в действии. Обычно все посетители, связанные с agile-сообществом разработки ПО, спрашивали об одном и том же: «Дэвид, мы увидели в офисе семь канбан-досок. Они все разные! Каждая команда работает по своему процессу! Как можно справиться с таким разнообразием?» На этот вопрос я обычно отвечал так: «Конечно! Все ситуации разные. Они развивают свой процесс в соответствии с контекстом». Но я знал, что все процессы ведут начало от одних и тех же принципов и что члены команд, осознавая эти базовые принципы, могут адаптировать их под собственные нужды.

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

Чтобы подчеркнуть этот выбор, я разработал дизайн футболки для Общества ограничения незавершенных задач. Я вдохновился постером Шепарда Фэйри для предвыборной кампании Обамы, на который поместил портрет Тайити Оно, создателя канбан-системы в Toyota. Слоган «Да, мы за канбан» призван подчеркнуть, что у вас есть возможность. Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна, и вы можете разработать собственное решение для своего процесса, оптимизированное для вашей сферы деятельности и потока создания ценности, рисков, с которыми вы сталкиваетесь, навыков вашей команды и требований ваших клиентов.

• Канбан-системы могут быть использованы в любой ситуации через ограничение наличия элементов работы внутри системы.

• Сады Императорского дворца в Токио используют канбан-систему, чтобы контролировать число посетителей в парке.

• Количество сигнальных карточек «канбан», находящихся в обращении, ограничивает объем незавершенных задач.

• Новая работа втягивается в процесс после возвращения в оборот сигнальной карточки, когда предыдущее задание выполнено.

• В IT-сфере мы, как правило, используем виртуальную канбан-систему, поскольку для ограничения количества незавершенных задач не передаются какие-либо физически существующие карточки.

• Доски со стикерами, часто встречающиеся в гибкой разработке ПО, не являются канбан-системами.

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

• Канбан-метод (или Канбан с большой буквы) использует канбан-систему как катализатор изменений.

• Канбан требует формальных политик процессов.

• Канбан использует инструменты разных областей знаний для анализа проблем и поиска решений.

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

• Современное определение Канбан-метода можно найти в сети на сайте Общества ограничения незавершенных задач (Limited WIP Society, ).

• Канбан дает разрешение на отклонения в разработке ПО, поощряет поиск специфических решений в зависимости от контекста вместо догматического следования определению процесса жизненного цикла разработки ПО или шаблону.