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

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

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

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

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

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

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

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

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

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

Переговоры по внедрению канбана

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

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

WIP-лимиты

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

Есть и другие варианты. Допустим, вы хотите, чтобы в команде работали попарно. А два задания на пару при общей численности десять программистов соответствуют WIP-лимиту, равному 10. Возможно также, что вы используете метод более тесного сотрудничества – например, разработку по функционалу или функциональные бригады. В этом случае небольшие группы по пять-шесть человек работают над одной MMF, пользовательской историей или одним пакетом функций (как в FDD), то есть над тем, что также называется рабочим пакетом главного программиста (CPWP – Chief Programmer Work Package). Команда функциональных разработчиков может договориться и ограничить число CPWP тремя на команду из десяти разработчиков. (CPWP обычно оптимизируется для эффективности разработки на основании архитектурного анализа домена и содержит от 5 до 15 очень детализированных функций.)

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