Канбан. Альтернативный путь в Agile - [67]

WIP-лимиты

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

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

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

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

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

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

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

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

Релиз

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