Читать онлайн «Канбан. Альтернативный путь в Agile». Страница 19

Эта схема характерна для первого внедрения канбан-системы в 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 сначала встречаются небольшие команды, а затем каждая из них посылает делегата на скрам-над-скрамом, чтобы скоординировать программу или большой проект. В Канбане все происходит наоборот: сначала – крупное совещание программного уровня.

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

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

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

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

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