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

Итак, мы поговорили с заинтересованными лицами о WIP-лимите. Мы обсудили, какой должна быть разумная многозадачность по отношению к предсказуемости релизов и ожидаемому времени выполнения. Достижение договоренности с партнерами о WIP-лимитах крайне необходимо. Хотя WIP-лимиты можно объявить и в одностороннем порядке, привлечение других заинтересованных лиц и достижение консенсуса устанавливает общие обязательства – теперь все должны придерживаться одинаковых правил. В будущем такие обязательства могут стать бесценными. Настанет день, когда партнеры попросят нас взять дополнительную работу. Они обязательно так сделают, потому что им покажется это важным и ценным. Они будут руководствоваться самыми благими намерениями. Но мы сможем ответить им, что у нас есть заранее оговоренный WIP-лимит и его надо уважать. Система к тому времени, вероятно, будет полной, и согласие взять дополнительный элемент будет означать превышение WIP-лимита. Поэтому наш ответ должен звучать так: «Мы охотно взяли бы новую работу, потому что понимаем, как она важна для вас. Но вы ведь знаете, что у нас есть заранее оговоренный WIP-лимит. Вы участвовали в этом решении и понимаете, почему мы его приняли. Мы хотим сохранить предсказуемость и своевременность обработки запросов. Чтобы взяться за ваш запрос, нам придется отложить в сторону другие. Какой из элементов, которые сейчас находятся в работе, мы, по-вашему, должны отложить, чтобы взяться за новый?»

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

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

Расстановка приоритетов

Мы хотим договориться и о механизме пополнения очереди. Обычно это достигается решением о проведении регулярного совещания по пополнению системы и определением механизма выбора новых элементов. Разговор можно начать так: «Если нам нужно будет спросить вас: “Какие два элемента вы хотите видеть реализованными через сорок два дня?” – то как часто вы сможете встречаться с нами, чтобы отвечать на этот вопрос? Надеемся, что такие совещания будут занимать не более получаса».

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

Релиз

Затем нужно договориться примерно о том же с партнерами ниже по цепочке. То, какая именно каденция релизов является целесообразной, очень зависит от отрасли или ситуации. Если речь идет о веб-программах, то их нужно поставлять на группу серверов. Реализация такой программы включает копирование файлов и, возможно, обновление схемы баз данных с последующим переносом данных с одной версии схемы на другую. Для переноса данных, вероятно, понадобится собственный код, а его выполнение может занять некоторое время. Чтобы вычислить общее время реализации, нужно учесть количество серверов и файлов для копирования, время на безопасное закрытие систем и их перезагрузку, на перенос данных и т. д. Иногда это занимает несколько минут, а порой – несколько часов или дней. В других отраслях нередко приходится создавать физические носители – DVD, упаковывать их в коробки и поставлять по физическим каналам, направляя распространителям, дилерам, розничным операторам или уже существующим корпоративным клиентам. Могут быть задействованы и другие виды деятельности – например, печать бумажных инструкций или обучение сотрудников отделов продаж и техподдержки. Иногда для этих людей нужно разрабатывать и отдельную программу обучения.

Например, в 2012 году я принимал участие в релизе первого из обновлений мобильной телефонной сети Sprint PCS. Это обновление на пути к технологии 3G называлось lxRTT. На рынок оно вышло как PCS Vision и включало выпуск примерно 15 новых аппаратов с 16 новыми функциями, которые использовали высокоскоростные возможности передачи данных новой сети. У Sprint в США была розничная сеть, где работали 17 тысяч человек. Примерно столько же было в кол-центрах, которые занимались технической поддержкой пользователей. И участники розничного канала продаж, и сотрудники техподдержки должны были пройти обучение, чтобы запуск нового сервиса стал эффективнее. Я в шутку предположил, что оптимальнее всего закрыть все на пару дней, вывезти всех на ночь в Канзас-Сити и арендовать стадион команды «Канзас-Сити Чифс», на котором и провести двухчасовую презентацию в PowerPoint на больших экранах в обоих концах стадиона. Возможно, это был самый эффективный, но, конечно, неприемлемый способ. Вряд ли клиенты одобрили бы 48-часовое отсутствие поддержки на время обучения операторов технологии следующего поколения. А двухдневное отсутствие продаж по розничному каналу явно не помогло бы годовому бюджету.

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

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

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

Время выполнения и классы обслуживания

Когда разговор заходит о времени выполнения, полезно привести накопленные данные по предыдущей производительности. В идеале хорошо иметь данные по времени выполнения и инженерному времени. В примере с Microsoft (глава 4) было известно, что время выполнения составляет примерно 125 дней на устранение ошибок первой степени срочности и 155 дней – на ошибки остальных степеней. Главное, что мы можем отсюда почерпнуть, – это наличие двух классов обслуживания. Ошибки первой степени в какой-то форме обрабатывались раньше. Возможно, формальных правил не было, но так уж выходило, что ошибки первой степени устранялись быстрее.

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

Также из предыдущих данных известно, что в среднем инженерная работа занимала 11 дней, а при самом высоком качестве работ – 15. Поэтому мы решили предложить 25-дневное время выполнения, считая с момента выбора элемента из входящей очереди. Больше никаких научных данных не потребовалось. А теперь представьте психологический эффект от этого: в бизнесе привыкли, что работа занимает четыре-пять месяцев, а мы предлагали 25 дней. Разница в том, что мы говорили о 25 днях как о времени выполнения, не учитывая ожидание в очереди, а 155 дней включали и его. Тем не менее это выглядело фантастическим улучшением. Неудивительно, что представители бизнеса согласились.

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