Канбан. Альтернативный путь в Agile

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

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

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

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

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

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

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

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

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

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

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

Анализ нагрузки

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

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

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