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

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

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

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

Добавив очередь для получения PTC, он обеспечил равномерный поток работы между разработкой и тестированием, что показано на рис. 4.4. Этот подход – использование буфера для снижения вариативности размеров и усилий – обсуждается в главе 19.

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

.

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

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

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

Рис. 4.5. Рабочий процесс с Канбаном: ограничение задач в работе и очереди

Он хотел предложить «гарантированное» время выполнения – 25 дней с момента попадания задачи во входящую очередь. Конечно, 25 больше, чем 11. А на некоторые задачи требовалось до 30 дней. Но Драгош решил, что таких заданий не должно быть много. И, кроме того, 25 – это гораздо меньше, чем 140, а именно столько дней составлял текущий срок выполнения работ. Он рассчитывал добиться цели благодаря регулярности поставок, построению доверительных отношений с менеджерами продукта и их клиентами.

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

Клиентам предложили отказаться от вычисления ROI и переводов бюджета между отделами на основе оценки планируемых трудозатрат. В обмен на это им пообещали беспрецедентно короткие сроки выполнения и надежность. Для удобства расчетов время обработки запроса – примерно 11 дней – устанавливалось на основании исторических данных, о чем говорилось выше, в разделе «Факторы, влияющие на производительность». Также их попросили считать затраты фиксированными и игнорировать ту калькуляционную парадигму, на которой ранее основывались переводы бюджета между отделами.