Часть III
Внедрение канбана

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

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

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

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

Вот основные типы работы в командах, использующих Канбан (это неполный список):

• требование;

• функция;

• пользовательская история;

• пользовательский сценарий;

• запрос изменений;

• дефект продукта;

• поддержка;

• рефакторинг из-за ошибки;

• предложение улучшения;

• блокирующая проблема.

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

Типы работы обычно определяются их источником, рабочим потоком или размером работы. Например, у производственных текстовых изменений (РТС) в примере с Microsoft из рабочий поток иной, хотя источник тот же, что и у запроса изменений. Иметь отдельные канбан-системы для обоих типов бессмысленно: работу выполняет одна и та же команда и несложно визуализировать типы, используя различные цвета карточек или разные ряды («плавательные дорожки») на стене карточек. Порядок величины карточек обычно таков: маленькие (несколько дней), средние (от недели до двух) и большие (месяц и более). Каждый порядок должен соответствовать своему типу.

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

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

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

Рис. 6.1. Черновик рабочего потока на стене карточек (поток движется справа налево)

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

Рис. 6.2. Специальная пленка для магнитной доски (rolls = рулоны)

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

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

Рис. 6.3. Рабочий поток с буферами и очередями

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

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

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

На момент написания этой книги нет достаточного объема данных, чтобы решить, какой подход лучше.

Рис. 6.4. Стена карточек, иллюстрирующая использование ромбовидных карточек в верхней части очереди и буферных столбцов (публикуется с разрешения Liquidnet Holdings)

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

Анализ нагрузки необходимо проводить для каждого определенного типа работы. Если у вас накопились данные, проведите на их основе количественный анализ. Если их нет, то подойдет и анализ на основе личного опыта. Например, в примере с Microsoft XIT из существовало два типа работы – запросы изменений и производственные текстовые изменения (PTC). Возможно, запросы изменений следовало тоже разбить на два типа – дефекты производства и собственно запросы изменений (для новой функциональности). Будь я сейчас наставником этой команды, я бы рекомендовал им различать четыре типа работ: запросы изменений, производственные дефекты, производственные текстовые изменения и ошибки (или неэкранированные дефекты).

Изучим нагрузку для каждого из этих типов. Нагрузка PTC носит пакетный характер: на протяжении шести недель их может не быть вовсе, а затем пройдет десяток за неделю, причем почти одновременно. PTC были небольшими и быстро внедрялись. Поэтому воздействие их не было критичным. Создание системы, способной справляться с такой прерывистой нагрузкой, – это сложная задача. Если PTC требовали серьезных усилий, то системе нужен был существенный встроенный резерв, чтобы справляться с PTC и при этом не снижать предсказуемость запросов изменений.

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

Нагрузка по некоторым типам работ, например регуляторным требованиям, носит сезонный характер. Новое налоговое законодательство также сезонно затрагивает финансовую систему и систему начисления заработной платы. Мне известен такой случай: IT-отдел автогоночной компании получал регуляторные изменения от контролирующей спортивной организации в начале каждого гоночного сезона. Их могли присылать и во время сезона, но в межсезонье объем был существенно больше, поскольку регуляторные требования менялись от сезона к сезону. Важно понимать принципы такой нагрузки, чтобы менять дизайн канбан-системы и лучше справляться с разными типами работы.

Поняв нагрузку, вы можете определить, какую мощность системы выделить на ее удовлетворение. В примере на  приведены три «плавательные дорожки», по одной для каждого типа работы, а именно для запросов изменений, внутренней эксплуатационной деятельности (например, рефакторинга кода) и производственных текстовых изменений. В итоге выделено 60 % на запросы изменений, 10 % на работу по рефакторингу кода и 30 % на производственные текстовые изменения. Учитывая анализ нагрузки, который показывает, что производственные текстовые изменения прибывают порциями, такое распределение мощности демонстрирует, что значительный резерв выделяется на срочную обработку производственных текстовых изменений сразу после их прибытия без ущерба для дедлайнов по другим работам. Распределение мощности должно учитывать профиль риска. Если, например, допустима просрочка выполнения заданий для производственных текстовых изменений, а время выполнения по запросам изменений может быть более длительным и менее предсказуемым, то распределение будет иным: например, 85 % на запросы изменений, 10 % на обслуживание и 5 % на производственные текстовые изменения. Еще один вариант – оставить «плавательную дорожку» для производственных текстовых изменений, но не выделять для них никакой мощности, а просто превысить ограничение числа незавершенных задач, если поступает пакет производственных текстовых изменений. Тем самым вы отказываетесь от ненужного резерва и выдаете оптимальный экономический результат при обычной работе. Однако когда пакет производственных текстовых изменений действительно прибывает, это может повлечь за собой серьезные последствия для всех других задач с точки зрения времени выполнения и предсказуемости.

Такой выбор сделан в реальном примере (), когда было решено не резервировать отдельные силы для работы с производственными текстовыми изменениями.

.

Рис. 6.5. Канбан-доска с типичными «плавательными дорожками», включая распределение мощности

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

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

.

Рис. 6.6. Увеличение участка стены карточек, демонстрирующее анатомию карточки

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

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

Системы управления задачами для канбан-систем применяются в разработке ПО с момента их первого внедрения в 2004 году. Но использование таких систем не обязательно. Правда, для географически распределенных команд или для коллективов, члены которых могут один либо несколько дней в неделю работать дома, система управления задачами необходима. Фиксировать задачи в электронном виде можно при помощи самых простых систем учета – например, Jira, Microsoft Team Foundation Server, Fog Bugz и HP Quality Center. Однако более мощная система позволяет визуализировать поток задач, как будто бы он находится на доске с карточками.

В настоящий момент на рынке появляются веб-сервисы и приложения для электронной визуализации. Они используют визуальные панели, которые симулируют стены карточек с их столбцами, ограничениями числа рабочих задач и другими сущностными характеристиками Канбана. Среди них есть (список, конечно, неполон) Lean Kit Kanban, Agile Zen, Target Process, Silver Catalyst, RadTrack, Kanbanery, VersionOne, Greenhopper for Jira, Flow.io и некоторые другие надстройки с открытым кодом, которые добавляют интерфейс Канбана к таким инструментам, как Team Foundation Server и FogBugz. Рис. 6.7 демонстрирует пример из AgileZen.

Рис. 6.7. Скриншот AgileZen, система управления задачами

Электронная фиксация задач необходима для команд, которые стремятся к большей организационной зрелости. Если вы чувствуете необходимость в количественном менеджменте, сопоставлении организационных процессов (сравнение производительности по канбан-системам, командам или проектам), то лучше с самого начала внедрить систему управления задачами.

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

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

Рис. 6.8. Пример очереди на вход «Готово к проектированию» (E.R.)

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

Есть два основных способа работы в такой ситуации. Один – не моделировать ее вовсе, а просто оставить одну колонку, в которой оба вида работы могут происходить одновременно (рис. 6.9). Это легко, но не нравится многим командам. Некоторые команды адаптировали эту модель и используют для разных видов деятельности различные цвета или формы карточек. Другой вариант – вертикально разделить доску на две (или более) секции (рис. 6.10).

Рис. 6.9. Открытый столбец для параллельных видов деятельности

Рис. 6.10. Разделенный столбец для параллельных видов деятельности

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

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

При моделировании канбан-систем важно помнить, что они должны отражать реальное выполнение работы.

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

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

Рис. 6.11. Открытый столбец для множества неупорядоченных видов деятельности

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

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

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

• Определите типы работы и смоделируйте рабочий поток для них. Для некоторых типов все этапы потока необязательны.

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

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

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

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