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

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

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

Расстановка приоритетов по мере необходимости или по запросу

Как уже говорилось в главе 4, в 2004 году Драгош Думитриу внедрил канбан-систему в своей команде инженерного обеспечения XIT в Microsoft. Соседями сверху по цепочке были четыре менеджера продукта, представлявшие несколько подразделений. Они собирали и расставляли в приоритетном порядке запросы на изменения примерно для 80 IT-систем, поддерживаемых XIT.

Когда мы с Драгошем разрабатывали канбан-систему для внедрения в XIT, мы спроектировали входящую очередь так, чтобы в нее помещалась по крайней мере неделя работы. Хотя все четыре бизнес-представителя и Драгош работали в Редмонде, в кампусе Microsoft, встречи по расстановке приоритетов проводились по телефону. Дело в том, что кампус Microsoft огромен, и номера заданий перевалили за сотню, хотя на самом деле зданий всего около сорока. Площадь кампуса – несколько квадратных километров, и между зданиями перемещаются на микроавтобусах или на Toyota Prius. Поэтому многие предпочитают проводить координационные совещания при помощи телефонных конференций, а не лично. Это отрицательно сказывается на уровне доверия и социального капитала среди сотрудников, но положительно – на эффективности.

Итак, Драгош организовал еженедельные телефонные совещания по расстановке приоритетов среди новых запросов на изменения в бэклоге. Четыре менеджера продукта представляли подразделения, которые спонсировали работу команды Драгоша. Основываясь на объеме поддержки, можно было предположить, как часто представитель того или иного подразделения сможет добавлять свою задачу в очередь. Так, менеджер продукта, который поставлял 60 % финансирования, имел право добавить в очередь свою задачу в трех случаях из пяти. Дискуссии между остальными также разрешались на основании сравнительного объема финансирования. Менеджер продукта, финансировавший работу команды меньше всех, мог добавить нужную ему задачу лишь в одном случае из одиннадцати. Таким образом, возник взвешенный циклический алгоритм выбора.

Итак, правила корпоративной игры, по методу которой осуществлялась расстановка приоритетов в XIT, были простыми. Каждую неделю менеджеры продукта заполняли освободившиеся места во входящей очереди – обычно их было три. Каждый из них получал право выбора в соответствии с алгоритмом. Время выполнения в соответствии с соглашением об уровне обслуживания составляло 25 дней. Поэтому, получая возможность выбрать запрос изменения для дальнейшей разработки, они должны были спросить себя: «Какие из элементов своего бэклога я больше всего хотел бы видеть реализованными через 25 дней?» Установился простой и четкий порядок, в котором они получали право на выбор, – он зависел от уровня финансирования ими отдела.

Поскольку правила были действительно несложными, совещания заканчивались очень быстро. Вскоре стало ясно, что даже координационный конференц-звонок был не так уж необходим. Драгош сделал так, что база данных Microsoft Product Studio (предшественник Visual Studio Team System, Team Foundation Server) автоматически посылала ему электронное письмо при освобождении места в очереди. Он пересылал это письмо менеджерам продукта. Они быстро выясняли, чья сейчас очередь, и этот человек делал свой выбор. Обычно освободившееся место заполнялось в течение двух часов. Исключительно низкие координационные издержки наряду с небольшими операционными издержками, связанными с решением не производить оценку запросов изменений, а также довольно высокая зрелость рабочей команды позволили Microsoft XIT отказаться от регулярного проведения совещаний по расстановке приоритетов.

Стоит заметить, что редмондский офис Microsoft имел примерно третий уровень зрелости, а поставщиком для разработки и тестирования XIT была команда пятого уровня зрелости, расположенная в Хайдарабаде. Таким образом, эта команда могла пользоваться преимуществами как низких координационных и операционных расходов, так и исключительно высокого уровня организационной зрелости. Вместе эти факторы означали, что расстановка приоритетов по запросу была для этой команды более эффективной.

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

Выводы

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