Визуальный контроль и вытягивание

 

Если говорить о Канбане, то самая популярная форма координации в нем – стена карточек. Обычно пределы числа незавершенных задач фиксируются на доске сверху каждого столбца или в интервалах между ними. Необходимость вытягивания возникает, когда количество карточек в столбце меньше заданного предела. На рис. 7.1 видно, что вверху столбца «Анализ» записан предел – четыре элемента. Карточек же в столбце всего три. Поскольку 4 – 3 = 1, это говорит о том, что мы можем добавить один элемент в столбец «Анализ» (функция системного анализа) из входящей очереди, «Готово к проектированию» (отмеченной на рис. 7.1 как E.R.). Входящая очередь имеет максимальный размер элементов, но в ней на данный момент осталось только два. После перевода одного из элементов в «Анализ» в очереди остается еще один (5 – 1 = 4). Это означает, что на следующем совещании по расстановке приоритетов можно будет добавить во входящую очередь четыре новых элемента.

 

Рис. 7.1. Представление пределов канбана на стене карточек

 

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

На рис. 7.2 в увеличенном виде показаны стикеры, которые соответствуют рабочим единицам на стене карточек. Чтобы передать сочетание типа единицы работы и класса обслуживания, используется цвет.

 

Рис. 7.2. Крупный план стены карточек с карточкой проблемы, прикрепленной к блокированной единице

 

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

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

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

 

Системы управления задачами

 

Альтернативой или дополнением к стене карточек в канбан‑системе служит электронная система управления задачами. Некоторые доступные для этого инструменты перечислены в главе 6. Более актуальный список есть на сайте Limited WIP Society: http://www.limitedwipsociety.org.

Мы с командой разработали собственное приложение – Digital Whiteboard (рис. 7.3), надстройку к Team Foundation Server. В кейсе из главы 4 электронное ведение задач проводилось при помощи внутреннего инструмента Microsoft под названием Product Studio. Это предшественник Team Foundation Server, и с 2005 года Microsoft пользуется Team Foundation Server для собственных внутренних проектов разработки.

 

Рис. 7.3. Приложение Digital Whiteboard, использовавшееся в Corbis

 

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

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

 

Ежедневные стендапы

 

Совещания в формате стендапов – широко распространенный элемент процесса agile‑разработки. Обычно они проходят до начала работы в заранее утвержденном формате. Типичное стендап‑совещание проводится для одной команды, состоящей максимум из двенадцати человек (чаще из шести). Формат предполагает обсуждение трех вопросов: чего вы добились вчера? Что вы будете делать сегодня? Что вам мешает, нужна ли помощь? Каждый член команды отвечает на эти вопросы, после чего группа координирует свою работу на текущий день.

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

Особое внимание уделяется блокированным (с прикрепленной розовой карточкой) и отложенным из‑за ошибок (с прикрепленными голубыми карточками) элементам. Могут быть заданы вопросы и по единицам работы, которые почему‑либо не продвигаются вперед уже несколько дней. Некоторые команды придумали способы их визуализации. Например, в итальянской автогоночной компании, которая также производит спорткары, принято ежедневно ставить точку рядом с карточкой, которая надолго застывает в одном и том же месте. Это позволяет команде задуматься, не пометить ли такой элемент как заблокированный, не участвующий в рабочем потоке. Таким образом улучшаются возможности организации по решению проблем (которые будут подробнее описаны в главе 20). Команда кратко обсуждает вопрос, кто работает над проблемой и когда она будет решена. Рассматривается также наличие других блокирующих проблем, которые не отражены на доске; желающим предлагается выступить. Наиболее зрелые команды со временем поймут, что совершенно необязательно анализировать все карточки. Достаточно проанализировать заблокированные или содержащие ошибки элементы. Этот механизм позволяет принять участие в таких совещаниях гораздо большему числу сотрудников: например, в 2007 году Дэниэл Ваканти проводил успешные стендапы для более чем 50 участников проекта в Corbis. Несмотря на огромный размер команды, эти утренние совещания длились не дольше десяти минут.

 

Постсовещание

 

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

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