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

 

Как уже говорилось в главе 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 была команда пятого уровня зрелости, расположенная в Хайдарабаде. Таким образом, эта команда могла пользоваться преимуществами как низких координационных и операционных расходов, так и исключительно высокого уровня организационной зрелости. Вместе эти факторы означали, что расстановка приоритетов по запросу была для этой команды более эффективной.

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

 

Выводы

 

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

• Канбан устраняет потенциальные проблемы в координации планирования итераций, возможные при agile‑методах, поскольку отделяет каденцию по расстановке приоритетов от времени выполнения разработки и поставки.

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

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

• Правила, связанные с расстановкой приоритетов и информацией для принятия решений, в Канбане применительно к разработке ПО представляют собой правила корпоративной игры.

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

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

• Можно увеличить эффективность расстановки приоритетов и ее каденцию, сосредоточившись на снижении операционных и координационных расходов.

• Частые совещания по расстановке приоритетов укрепляют доверие.

• Регулярные встречи по расстановке приоритетов снижают координационные расходы и особенно полезны в организациях с низкой степенью зрелости.

• Расстановка приоритетов по мере необходимости или по запросу подходит для очень зрелых организаций с высоким уровнем доверия и низкими расходами на расстановку приоритетов.

 

 

Глава 10

Задание WIP‑лимитов

 

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

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

 

Лимиты на рабочие задания

 

Драгош Думитриу в команде XIT в Microsoft решил, что разработчики и тестировщики не должны работать одновременно более чем над одним заданием. Никакой многозадачности. Объявление было сделано в одностороннем порядке, но, к счастью, не привело к проблемам с другими заинтересованными лицами. Это соответствовало текущим методам работы и индивидуальному процессу разработки ПО (PSP), принятому в то время в команде. Организация обладала достаточной степенью зрелости, чтобы поддерживать дисциплину и следовать заранее установленным процедурам. Как уже упоминалось, осенью 2004 года в команде было три разработчика и три тестировщика. Таким образом, WIP‑лимит на разработку и тестирование равнялся трем.

В 2006 году в Corbis, выступив с инициативой в области инженерного обеспечения, мы приняли такое же решение: аналитики, разработчики и тестировщики должны работать над одной задачей одновременно. Для новых крупных проектов мы принимали другие решения. Работа над ними предусматривала увеличение численности команды. Нередко над одной задачей трудились небольшие команды из двух‑трех человек. Поскольку эти задачи могли блокироваться или откладываться, мы решили использовать переключение между задачами и дополнительную параллельность в работе, поэтому WIP‑лимит был задан с таким расчетом, чтобы над единицей работали два‑три человека, но допускалось некоторое перекрытие задач. Например, если у нас было десять человек и расчет «два человека на задачу», то WIP‑лимит составил бы пять плюс еще немного, чтобы нивелировать возможный эффект от блокировки. В таких обстоятельствах подходящее значение лимита – 8 (5 + 3).

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

Никакой общей формулы успеха здесь не существует. Важно помнить, что значение WIP‑лимита меняется на основе эмпирических данных. Вы можете выбрать значение и затем решить, насколько оно удачно. Если нет, увеличьте его или сократите.

 

Лимиты на очереди

 

Когда работа закончена и элемент дожидается, пока его вытянут на следующую стадию, говорят, что он находится в очереди. Какой должна быть эта очередь? В идеале как можно короче. WIP‑лимит для очереди часто объединяется с предыдущим этапом работы.

Например, очереди «Разработка» и «Готово к разработке» объединены, как показано на рис. 10.1. Если установлены действительно жесткие правила по WIP‑лимитам, например строго один элемент на одного‑двух человек или на небольшую команду, то необходимо организовать очередь, чтобы поддерживать рабочие задания и амортизировать вариативность. Когда ваша канбан‑система на практике страдает от политики «остановка‑запуск», которая вынуждает сотрудников к простою из‑за того, что на выполнение заданий требуется разное время, стоит подумать об увеличении размеров очереди. Однако если вы сделали выбор в пользу, например, двух задач на одного‑двух человек или на команду, то буфер для амортизации вариативности уже организован, так что размер очереди часто будет равен нулю. Просто объедините столбец рабочих задач с очередью.

 

Рис. 10.1. Стена карточек, демонстрирующая различные типы очередей и буфер