Канбан. Альтернативный путь в Agile Андерсон Дэвид

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

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

Собрания по пополнению очереди

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

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

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

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

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

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

Совещания по планированию поставок

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

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

У зрелой компании обычно готова технологическая карта или структура релиза, что облегчает планирование. Вот некоторые вопросы, которые нужно принимать во внимание:

• Какие элементы системы готовы (или будут готовы) для релиза?

• Что требуется, чтобы действительно подготовить релиз всех элементов?

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

• С какими рисками это сопряжено?

• Как эти риски минимизировать?

• Какие планы экстренных мероприятий потребуются?

• Кто будет участвовать в релизе до момента его запуска в производство или другого механизма выполнения?

• Сколько времени займет релиз?

• Что еще для него необходимо?

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

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

Триаж

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

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

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

Триаж бэклога нужно проводить сравнительно нечасто. (Заметим, что в некоторых методах гибкой разработки ПО он называется «грумингом».) Разные команды предпочитают различную периодичность – ежемесячно, ежеквартально, дважды в год. При триаже бэклога обычно присутствуют те же владельцы продукта и представители бизнеса, которые ходят на собрания по пополнению очереди, а также менеджер проекта. Технических сотрудников немного – нередко они представлены одним менеджером среднего звена.

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

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

Цель проведения триажа бэклога – сокращение его размеров. Преимущество меньшего размера бэклога – в облегчении процедуры обсуждения приоритетов. Выбирать из 200 элементов гораздо проще, чем из 2000.

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

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

Анализ журнала проблем и эскалация наверх

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

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

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

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

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

Стикерные представители

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

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

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

Синхронизация по географическим зонам

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

На самом деле все наоборот. Первая команда в Microsoft (из главы 4) находилась в индийском Хайдарабаде, в то время как руководство и владельцы продукта размещались в американском Редмонде. У компании Corbis, описанной в главе 5, тоже были команды и в Индии, и в других местах за пределами Сиэтла – например, в Лос-Анджелесе и Нью-Йорке, и это не считая людей, периодически работавших дома.

Решить вопрос координации между разными местами можно при помощи электронной системы. Одной стены карточек недостаточно.

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

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

Выводы

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

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

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

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

• Расстановка приоритетов и планирование релиза должны проводиться независимо друг от друга и иметь свой собственный ритм.

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

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

• Регулярный триаж бэклога в целях его сокращения положительно влияет на скорость и эффективность совещаний по расстановке приоритетов.

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

• Способы и методы передачи проблем высшему руководству должны быть четко определены.

Раздел 3 (главы 6–15) описывает механизмы внедрения канбан-системы, заканчиваясь главой 15, где говорится о том, как выступить с инициативой перехода на Канбан. Инициация перехода требует договоренности с различными внешними заинтересованными лицами, а не только с клиентами, типичными для компаний по разработке и их партнеров. Например, эта новая договоренность предполагает обязательство по регулярной выдаче работающего продукта.

Термин «каденция поставки» предполагает установление паттерна выдачи релизов работающего продукта с регулярными интервалами. Например, если мы договорились выдавать продукт каждые две недели, то каденция поставки будет составлять раз в две недели, или 26 раз в год. Возможно, появится даже решение по конкретному дню поставки. Например, каждую вторую среду, как это было с корректировочными версиями IT-приложений в Corbis.

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

Канбан избавляется от ограниченных во времени итераций и вместо этого рассинхронизирует деятельность по расстановке приоритетов, разработке и поставке. Каденция для каждой из них устанавливается и корректируется естественным образом. Однако Канбан не отказывается от понятия «регулярная каденция». Канбан-команды по-прежнему с заданной частотой выдают версии продукта, предпочитая короткие интервалы. Метод тоже работает в соответствии с «Принципами манифеста гибкой разработки»{19}. Однако Канбан старается избегать любых крайностей, связанных с искусственной установкой временных рамок для задач.

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

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

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

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

Координационные затраты на релиз

Координация любого программного релиза связана с затратами. Необходимо собрать людей для обсуждения выпуска, производства, упаковки, маркетинга, работы с потенциальными клиентами, документации, подготовки конечных пользователей, дилеров, отдела справок и службы технической поддержки, документации и процедур по установке, дежурных сотрудников, расписания выпуска и т. д. Планирование поставки элемента работающей программы бывает невероятно сложным – все зависит от отрасли бизнеса и типа программы. Обновление сайта, например, может оказаться тривиальной задачей по сравнению с обновлением прошивки военного оборудования, используемого по всему миру, спутников на орбите, боевого самолета или узлов телефонной сети. В 2002 году, когда мы планировали релиз обновления PCS Vision для американской сети сотовых телефонов Sprint PCS, требовалось обучить десятки тысяч людей. Нужно было объяснить 17 тысячам продавцов по всей стране, как работают около 15 новых телефонов, выводимых на рынок. Примерно такому же количеству человек предстояло объяснить, как отвечать на неизбежные звонки в службу техподдержки, которые обязательно последуют, когда неопытные клиенты приобретут свои новые устройства. Одно только планирование обучения 30 тысяч человек обходится недешево.

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

• Сколько совещаний?

• Сколько людей?

• Сколько времени это займет?

• Каков будет ущерб в результате отрыва людей от их основной работы?

Операционные расходы релиза

В случае с физически существующими товарами легко представить себе операционные расходы. Первый из них – платеж. Клиент платит поставщику, используя некое платежное средство, например кредитную карточку. За удовольствие получить платеж по кредитной карте ведущие компании в этой сфере, например MasterCard и Visa, взимают с продавца операционные расходы, обычно составляющие 2–4 % от стоимости сделки.

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

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

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

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

Так, некоторые фирмы, например Microsoft, продолжают производить «окончательные версии для промышленной эксплуатации» (RTM) и выпускают физические носители – DVD, упаковывают их и рассылают распространителям, розничным операторам и другим партнерам. Если ПО – часть встроенной системы, то необходимой может оказаться поставка чипов или, по крайней мере, запись программного кода в прошивку при помощи таких технологий, как EE-PROM. Чипы после этого, вероятнее всего, придется вмонтировать в оборудование, которое они призваны контролировать.

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

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

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

Эффективность поставки

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

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

Мы знаем, что дополнительные накладные расходы на релиз равны 200 тысячам, но какая часть из 1,3 миллиона потрачена на планирование, координацию и поставку продукта? Если у нас есть подходящие данные по учету рабочего времени, то можно посчитать и это. Но даже если их нет, мы все-таки способны сделать близкое к истине предположение. Сколько совещаний, людей? Как долго длились совещания? Включите сюда и число человеко-часов, потраченных на сдачу продукта. Умножьте на часовую ставку. Если результат составил около 300 тысяч долларов, то мы получили величину операционных и координационных издержек релиза на полмиллиона.

Эффективность релиза в процентах = 100 %  (общие затраты – (координационные затраты + операционные затраты)) / общая стоимость программного релиза.

В нашем примере эффективность равна

100 %  (1 500 000 – 500 000) / 1 500 000 = 66,7 %.

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

Какая эффективность считается достаточной?

Этот вопрос остается открытым. У всех компаний свои взгляды на достаточные показатели эффективности, и многое зависит от создаваемой ценности.

Формирование каденции поставки

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

Эффективность релиза в процентах = 100 %  (1 – ((операционные затраты + координационные затраты) / (прибыль + операционные затраты + координационные затраты))).

В нашем примере показатель эффективности составит

100 %  (1 (500 000 / (500 000 + 500 000))) = 50 %.

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

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

Если команде из пятидесяти человек требуется три дня и десять сотрудников для успешной выдачи кода, то стоит ли выпускать релиз каждые десять рабочих дней (то есть две календарные недели)? Ответ, вероятно, отрицательный. Лучше установить месячную каденцию (то есть двадцать рабочих дней). Но в то же время не стоит забывать об особенностях рынка, где гибкость и время выхода на рынок имеют большое значение, а риски в основном гасятся более частыми релизами. Так что игра стоит свеч. Вы должны все взвесить и принять самостоятельное решение.

Увеличение эффективности для ускорения каденции поставок

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

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

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

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

Релизы по запросу и по ситуации

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

Регулярные релизы также помогают создать доверие. А недостаток предсказуемости его разрушает. Отсутствие релиза в назначенную дату привлекает гораздо больше внимания, чем конкретное содержание этого релиза.

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

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

Такая почти непрерывная выдача кода полезна для некоторых отраслей. Примеры, известные мне от ранних последователей Канбана, в основном связаны с медиаиндустрией: это, в частности, IPC Media в Лондоне, где используются многочисленные канбан-системы для планирования разработок онлайн-медиа, например mousebreaker.com, невероятно популярной онлайн-игры.

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