Продолжение публикации учебного кейса из программы тренинга Kanban Systems Improvement (KMP II) от Канбан Университета.

Оглавление:

• Часть 1.
• Часть 2.
• Часть 3.
• Часть 4.
• Часть 5.

Потоковая система

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

Канбан-система

В таблице на Рис. 5 приведена сводная информация об изменениях прото- Канбан-системы 2008 г. с целью перехода на полноценную Канбан-систему в 2009 г. Спринты (итерации) были заменены потоковой системой с работой по требованию с двадцати однодневным SLA (соглашение об уровне обслуживания). Такой SLA был выбран неспроста: он соответствовал длине предыдущих трех недельных спринтов. Цель была в том, чтобы рабочие элементы были достаточно маленького объема, который можно было бы завершить в течение трех недель. При этом нужно было как-то всех успокоить, что работа не займет больше времени без наличия границ спринта или конкретных обещаний на поставку. В то время существовал широко распространенный миф, что отсутствие обязательств по выполнению работы в установленные сроки, например, к концу спринта, приведет к отсутствию целенаправленности, лени и все более длительным срокам выполнения работы.

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

В качестве Agile-коучей Posit использовала консультантов одного известного разработчика программного обеспечения. У них была долгая история активного противодействия внедрению Канбана в компаниях клиентов, хотя по иронии судьбы они использовали Канбан-систему для разработки собственного программного обеспечения. Поскольку их продукт был разработан для Скрам-фреймворка, они не хотели, чтобы их клиенты использовали Канбан. В Posit существовала значительная мотивация к переменам. К тому времени консультанты больше не могли использовать аргумент «отсутствии дисциплины» и “это вина людей из Posit, а не Скрама”. Они потеряли контроль над ситуацией по разработке программного обеспечения и Posit не стала продлевать с ними контракт. Однако страхи, которые они породили, все еще присутствовали и их нужно было как-то проработать. Чтобы это сделать, Дженис добавила в соглашение об уровне обслуживания гарантию поставки в течение трех недель.

В дополнение к двадцати однодневному SLA был изменен подход к оценке работы. Вы наверняка помните, что начинали они с очень точного метода оценки, определяющего, сколько человеко-часов понадобится на каждую задачу. Этот подход был описан одним из основателей Скрама Кеном Швабером. В то время такой подход был предпочтительным в консалтинговой фирме, оказывающей помощь Posit. На самом деле точные оценки не представляли особой ценности, поскольку они имели очень низкую вероятность быть точными. Вместе с переходом на прото-Канбан разработчики перешли от оценки задач в человеко-часах к определению размера футболок пользовательских историй. Это вывело их на более высокий уровень иерархии, поскольку истории обычно состоят из задач. Следовательно, потребность в анализе стала меньше, а оценка на уровне истории проходила быстрее. Они надеялись, что этот подход также будет иметь большую точность и информационную ценность. Год спустя они почти полностью отказались от оценки на уровне историй и вышли на другой более высокий уровень функциональной иерархии. Больше не было необходимости разбивать функции на пользовательские истории, чтобы брать на себя обязательства. Процесс оценки проходил следующим образом: после объяснения требований команде проходило голосование большим пальцем вверх или вниз. Всё обсуждение занимало несколько минут. Если команда была уверены в том, что функция может быть завершена в рамках SLA, она отмечалась как готовая к вытягиванию. Если нет, то владельцу бизнес-направления задавались уточняющие вопросы, чтобы переосмыслить требование и проголосовать за функцию еще раз. Эти изменения обобщены на Рис. 5.

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

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

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

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

Встречи по пополнению очереди проводились с помощью небольшой доски (Рис. 6). Она имела четыре области:

• Топ 10.
• В работе.
• Готово.
• Легенда.

В области “Топ 10” находилась входящая очередь. Она была пронумерована от 1 по 10. Но это не означало, что работу из очереди нужно брать строго в этом порядке. В связи с характером деятельности в Posit было много разных специализаций и неоднородности среди рабочей силы и работы, поэтому и Скрам-команды не были однородными по набору навыков. Когда какая-нибудь команда заканчивала работу над очередным элементом и готова была начать другой, первый элемент в очереди мог не подходить для нее по набору нужных компетенций. В этом случае команда шла вниз по списку до тех пор, пока не находила первый подходящий для себя элемент. Поэтому входная очередь в Posit была организована по принципу FIFO (first-in, first-out), а не в виде пополняемого буфера (иногда называемого в  Lean-литературе «супермаркетом»), реализованного в Microsoft или Corbis. Также в Топ-10 было выделено два слота для работы с нематериальным классом обслуживания. 

Область «В работе» показывала, что сейчас в работе у каждой из трех Скрам-команд. Вместо названий у команд была маркировка A, B и С. Это говорило о том, что социальная сплоченность была на уровне всего департамента и люди не сильно отождествляли себя с более мелкими командами, в которых работали. Команды назывались именно Скрам-командами, несмотря на использование Канбана, развязанные каденции планирования, поставки и времени выполнения, а также отказ от спринтов с временными рамками. Цифры под буквой команды обозначали количество дней, прошедших с момента вытягивания элемента в работу. 

На Рис. 6 мы также можем видеть причину следующей встречи по пополнению: команда B завершила работу над функцией и вытащила в работу первый элемент из Топ-10. Позиции со 2 по 10 должны сместиться вверх и следовательно нужно выбрать новый элемент для слота под номером 10. 

Элементы “В работе” также имеют особые отметки. Цветные кружки обозначают взаимные зависимости. Например элементы, которые должны быть поставлены вместе, имеют один и тот же цвет. Маленькие флуоресцентные закладки указывают на проблемы с блокировками, которые могут привести к превышению SLA. 

Область «Готово» – это “полка с трофеями” или “место” для функций, завершенных в недавнем прошлом. Эта область дает возможность поразмышлять о проделанной работе и ощутить достигнутый результат. «Готово» также информирует владельцев бизнес-стримов о том, «что мы, как команда разработки, сделали для вас в последнее время», и о ценности, которую мы регулярно поставляем.

Область «Легенда» содержит информацию о классах обслуживания: соответствующие им цвета карточек с графиками стоимости задержки и доступной мощностью, а также другие политики, связанные с классами обслуживания. Для “срочных” элементов WIP-лимит равен единице, а у “нематериальных” – двум. На Рис. 6 может показаться, что на доске есть четвертая команда X. На самом деле это обозначение ускоренной полосы. Дело в том, что специальной команды для ускоренных запросов не было. “Срочный” класс обслуживания был нужен для превышения WIP-лимита. Для выполнения такого запроса формировалась временная кросс-функциональная команда. Разработчики брались из всех трех команд. Если предположить, что ни одна команда при этом не была на 100% использована под срочный элемент, работа должна была продолжаться и над функциями “в работе”. 

Как уже упоминалось, не все элементы Скрама были заменены практиками Канбана. Остались роли Скрам-мастера и Владельца Продукта, ежедневный «Скрам» (хотя, по сути, это уже был ежедневный Канбан-митинг), демонстрации, ретроспективы и приемка владельцем продукта.

Демонстрации и ретроспективы проводились также один раз в три недели в одно и то же время и в один и тот же день, что и в случае спринтов в Скраме. Здесь не было никаких изменений. Приемка Владельцем продукта также продолжалась, как и прежде. Однако теперь это было действие по требованию и касалось только работы в колонке на доске, как показано на Рис. 7. Обязанности Владельца продукта также остались без изменений.

На рис. 7 показан дизайн новой потоковой Канбан-системы. Рассмотрим его внимательней. Из общего количества функций для поставки будут выбраны десять лучших. Теперь очередь Топ-10 содержит интересное нововведение. Она имеет двухфазное, асинхронное обязательство. В примерах Microsoft и Corbis обязательства заказчиков и сервиса поставки синхронны: обе стороны присутствуют на встрече по пополнению и берут на себя взаимные обязательства. Заказчик говорит: «Я хочу, чтобы следующим вы сделали это«, а сервис поставки отвечает: «Окей, мы сделаем следующим  это для вас». Конструкция Posit отменяет синхронное обязательство. Вместо этого происходит следующее: на встречах по пополнению владельцы бизнес-стримов отбирают новые элементы для Топ-10, но сервис поставки не берет на себя обязательства ни по одному из них. Принятия обязательств происходит, когда Скрам-команда вытягивает элемент в колонку «Дизайн/Спецификация». Только после этого возникает двустороннее обязательство и начинается обратный отсчет в SLA. Асинхронное обязательство имеет некоторые преимущества. Оно может быть полезно, когда трудно организовать встречи с участием всех заинтересованных лиц. Однако его наличие, как правило, свидетельствует об организации с более низким уровнем зрелости, с меньшим доверием и меньшим уровнем сотрудничества. Вряд ли стоит рассчитывать на «магию Канбана», если вам не удастся собрать вместе людей из восходящих и нисходящих потоков выполнения работы.

Средняя скорость поставки в Posit составляла около одной функции в неделю. Следовательно, количество задач в работе вместе с Топ-10 представляли собой объем работы примерно на три месяца. Некоторые функции могли ожидать десять и более недель, прежде чем их возьмут в работу. Предполагалось, что некоторые элементы из Топ-10 будут выполнены в течение следующих трех месяцев. Следовательно маркетинг и PR могли использовать Топ-10 в качестве первичного сигнала для оценки времени выполнения или даже планирования поставки. Это можно было делать, как только элемент попадал в Топ-10. Однако, поскольку сервис поставки в свою очередь обязательств по нему еще не давал, элемент не оказывал никакого влияния на поставку других элементов. Поэтому Заказчику было разрешено менять в Топ-10 свои элементы во время встреч по пополнению на другие более срочные и важные функции.

Топ-10 обеспечивала возможность первичного сигнала. Он облегчал уведомление о сроках и отложенных обязательствах. Благодаря этому примеру концепция асинхронных обязательств во входящей очереди позже использовалась в других реализациях Канбана. Sami Honkonen рассказывал о компании, которая использовала визуальный календарь для обозначения работ, которые должны были быть начаты через тринадцать недель.

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

Итак, Канбан-доска Posit имела три дорожки для Скрам-команд и одну дорожку для срочных запросов. Доска была двухуровневой. Каждая функция (большая карточка) занимала одну дорожку и разбивалась на истории в виде маленьких карточек. Истории – дочерние элементы «родительской» функции – шли по доске. После завершения этапа тестирования программного обеспечения, функция целиком вытягивалась в этап клинического тестирования. Существовала опасность, что функция окажется слишком большой и не впишется в двадцати однодневный SLA. Чтобы снизить влияние этой опасности, Posit использовала стратегию, которую я называю «ловля мошенников с кредитками «. Они могли пропустить в систему “слишком большой” элемент, и дальше им нужно было быстро в течение дня или двух это понять. Также они создавали небольшой запрос с целью получения информации об элементе и оценивали его голосованием большого пальца вверх или вниз, чтобы уменьшить вероятность того, что что-то слишком большое войдет в систему. Обратите внимание, что некоторые элементы в Топ-10 имели соответствующие отметки. Это говорит о том, что разработчики – сервис поставки – были уверены, что функцию можно сделать за двадцать один день. Естественно, такой подход не был стопроцентным, но процент больших пропущенных с систему элементов должен был  быть небольшим. Также разработчики могли сообщать о слишком больших функциях, если это обнаруживалось после начала работы. У Posit было три варианта действий в этом случае:

1. Сделать в любом случае. Мы хотим этого. Нам это нужно. Это срочно, поэтому нам все равно, если это займет больше трех недель.
2. Сократить объём. Предложить владельцам бизнес-стримов ознакомиться с полученным в результате разбивки историями и отказаться от тех, которые не нужно делать.
3. Вернуть в бэклог. Вернуть в бэклог и попросить владельцев бизнес-стримов выбрать что-нибудь более простое.

На рисунке 8 показана пересмотренная в 2009 году форма запроса новой функции, используемая владельцами бизнес-стримов. В ней введено обязательное поле с указанием стоимости задержки и требуемого класса обслуживания, а действующее поле с информацией о возврате инвестиций стало необязательным. Владельцев бизнес-стримов не просят отказаться от существующего способа работы, а просто просят предоставить некоторую простую дополнительную информацию, которая будет полезна. Отмеченная желтым стоимость задержки – это серая белка или “новый вид, вошедший в экосистему”; отмеченная красным окупаемость инвестиций – это красная белка или “действующий вид в экосистеме”, который будет вытеснен более сильной альтернативой. В течение следующих шести недель ни один из владельцев бизнес-стримов не заполнял необязательный раздел формы, посвященный возврату инвестиций. Обсуждение стоимости задержки на еженедельных совещаниях по пополнению очереди оказалось достаточным для принятия качественных решений по отбору элементов в работу, их приоритету и графику работ. Мы наткнулись на данную форму в формате .doc год спустя. Нижняя часть формы была поистине эволюционным реликтом. Как видите, она все еще была там. Несмотря на то, что она не использовалась уже год, никто ее не удалял и даже не обсуждал возможность ее удаления.

На рисунке 9 показан снимок фактической доски 2009 года. Фотография приведена для демонстрации некоторых интересных элементов дизайна и реализации Канбан-системы. 

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

Клиническое тестирование, обозначенное на доске, как QA, имеет в колонке WIP-лимит. Это говорит о том, что клиническое тестирование – это общий сервис, который обслуживает все Скрам-команды и ускоренную команду, если такая есть в данный момент. Если бы клинические тестировщики находились внутри кросс-функциональных Скрам-команд, как предписывает руководство по Скраму, то на колонке QA не было бы WIP-лимита, как и в предыдущей колонке “Test”. 

Также WIP-лимит установлен в колонке “Deploy”. Поскольку сборка релиза была нетривиальной, только один человек в компании имел на это право (речь идет о концепции «Золотого кода», когда релиз выпускается на «золотом» перезаписываемом компакт-диске, который, в свою очередь, передаётся производственному предприятию, выпускающему компакт-диски). Поскольку трансакционные издержки были высоки, было важно, чтобы конфигурация на диске была идеальной. Как таковой, этот этап в Posit был потенциально узким местом – WIP-лимит там установлен для того, чтобы защитить это узкое место от перегрузки. 

WIP-лимит также стоит в столбце “Accept”. Напомним, что Дэвид Хоффман играл в Posit роль Владельца продукта. Владелец продукта должен делать много вещей, одна из которых – принимать инкремент продукта, посещая каждую ретроспективу и обзор спринта. Однако, проблема «глобального потепления» в компании Posit – заканчивающиеся деньги – отнимала много времени у менеджеров, поэтому Дэвид не мог присутствовать на всех ретроспективах и не принимал выполненную работу. 

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

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

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

Однако, поразмыслив, они пришли к выводу, что приемка по-прежнему важна и должна остаться по причинам, связанным с руководством, управлением рисками и моральным состоянием персонала. Как же решить проблему своевременной приемки? Предложение состояло в том, чтобы установить на приёмке WIP-лимит. 

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

Однако установление WIP-лимита на внешнюю зависимость – это опасный выбор. Что делать, если внешняя зависимость не захочет сотрудничать и Судный день всё-таки наступит? Это говорит нам о том, что WIP-лимиты на внешние зависимости – не для новичков! Однако в данном случае у Дженис было смягчающее обстоятельство. Дэвид Хоффман, внешняя зависимость, сотрудничал с командой разработчиков. Он не собирался никого подводить, и Судный день никогда не должен был наступить.

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

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

Продолжение здесь.