Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Лимиты на рабочие задания
Драгош Думитриу в команде XIT в Microsoft решил, что разработчики и тестировщики не должны работать одновременно более чем над одним заданием. Никакой многозадачности. Объявление было сделано в одностороннем порядке, но, к счастью, не привело к проблемам с другими заинтересованными лицами. Это соответствовало текущим методам работы и индивидуальному процессу разработки ПО (PSP), принятому в то время в команде. Организация обладала достаточной степенью зрелости, чтобы поддерживать дисциплину и следовать заранее установленным процедурам. Как уже упоминалось, осенью 2004 года в команде было три разработчика и три тестировщика. Таким образом, WIP-лимит на разработку и тестирование равнялся трем.
В 2006 году в Corbis, выступив с инициативой в области инженерного обеспечения, мы приняли такое же решение: аналитики, разработчики и тестировщики должны работать над одной задачей одновременно. Для новых крупных проектов мы принимали другие решения. Работа над ними предусматривала увеличение численности команды. Нередко над одной задачей трудились небольшие команды из двух-трех человек. Поскольку эти задачи могли блокироваться или откладываться, мы решили использовать переключение между задачами и дополнительную параллельность в работе, поэтому WIP-лимит был задан с таким расчетом, чтобы над единицей работали два-три человека, но допускалось некоторое перекрытие задач. Например, если у нас было десять человек и расчет «два человека на задачу», то WIP-лимит составил бы пять плюс еще немного, чтобы нивелировать возможный эффект от блокировки. В таких обстоятельствах подходящее значение лимита – 8 (5 + 3).
Некоторых авторов исследования и эмпирические наблюдения привели к мысли, что две задачи в работе на одного квалифицированного специалиста – это оптимальный вариант. Часто этот вывод приводят в качестве оправдания многозадачности. Однако я считаю, что эти наблюдения отражают только состояние в изучаемых организациях, где существует множество задержек и причин для откладывания работы. В исследованиях не отражена организационная зрелость компаний, к тому же они не соотносятся с данными внешних источников (варианты систематических погрешностей, о которых пойдет речь в главе 19). Таким образом, результат может отражать только изучаемые условия и не подходить для иных ситуаций. Тем не менее нужно быть готовым к тому, что решение брать не более одной задачи в работу на одного-двух сотрудников или на небольшую команду встретит сопротивление как слишком жесткий вариант. В таком случае разумно сделать WIP-лимит для одного-двух сотрудников или на команду. Порой приемлем и лимит в три задачи.
Никакой общей формулы успеха здесь не существует. Важно помнить, что значение WIP-лимита меняется на основе эмпирических данных. Вы можете выбрать значение и затем решить, насколько оно удачно. Если нет, увеличьте его или сократите.
Лимиты на очереди
Когда работа закончена и элемент дожидается, пока его вытянут на следующую стадию, говорят, что он находится в очереди. Какой должна быть эта очередь? В идеале как можно короче. WIP-лимит для очереди часто объединяется с предыдущим этапом работы.
Например, очереди «Разработка» и «Готово к разработке» объединены, как показано на рис. 10.1. Если установлены действительно жесткие правила по WIP-лимитам, например строго один элемент на одного-двух человек или на небольшую команду, то необходимо организовать очередь, чтобы поддерживать рабочие задания и амортизировать вариативность. Когда ваша канбан-система на практике страдает от политики «остановка-запуск», которая вынуждает сотрудников к простою из-за того, что на выполнение заданий требуется разное время, стоит подумать об увеличении размеров очереди. Однако если вы сделали выбор в пользу, например, двух задач на одного-двух человек или на команду, то буфер для амортизации вариативности уже организован, так что размер очереди часто будет равен нулю. Просто объедините столбец рабочих задач с очередью.
Рис. 10.1. Стена карточек, демонстрирующая различные типы очередей и буфер
Буфер для бутылочного горлышка
Бутылочное горлышко в рабочем потоке может потребовать буфера перед ним, как показано на рис. 10.1. Это типичный механизм амортизации бутылочных горлышек, о чем будет рассказано в главе 16. Важен масштаб буфера – желательно, чтобы он был как можно меньше. Буферы и очереди вносят в систему незавершенные задачи, что увеличивает время выполнения. Однако буферы и очереди делают рабочий поток более равномерным, что улучшает предсказуемость времени выполнения. Тем самым они увеличивают пропускную способность, и канбан-система может обработать больше задач. Буферы также сохраняют более равномерную занятость людей. Необходим баланс, который и помогают поддерживать буферы. Во многих случаях приходится стремиться к деловой гибкости и более короткому времени выполнения, а также повышению качества, связанному с меньшим количеством незавершенных задач. Однако в погоне за гибкостью или качеством не стоит жертвовать предсказуемостью. Если размеры очереди и буфера слишком малы, так что ваша система страдает от политики «остановка-запуск», вызванной вариативностью, то время выполнения окажется непредсказуемым, а вариативность – огромной. Выбирая WIP-лимит для буфера, нужно иметь в виду, что он должен быть достаточно большим, чтобы обеспечить равномерный ход работы по системе и исключить простой перед бутылочными горлышками. Подробнее о масштабах буфера и о том, как создать буферы для бутылочных горлышек с ограниченной пропускной способностью и задержкой доступа элементов, мы расскажем в главе 16.
Размер входящей очереди
Размер входящей очереди можно установить исходя из каденции расстановки приоритетов и пропускной способности, или темпа производства системы. Например, если команда выпускает в среднем пять законченных элементов в неделю (обычно – от четырех до семи в неделю) при установленной еженедельной каденции пополнения очереди, то наиболее вероятный размер очереди – семь. Впрочем, возможны эмпирические поправки. Если система в ходу уже на протяжении несколько месяцев и очередь за это время ни разу полностью не истощилась перед совещаниями по расстановке приоритетов, то, вероятно, ее размер слишком велик, нужно уменьшить ее на одну позицию и посмотреть на результаты. Повторяйте до тех пор, пока на одном из совещаний по приоритетам вы не предложите представителям отделов заполнить все места в очереди.
Если же совещания по расстановке приоритетов проводятся по понедельникам, а очередь исчерпалась уже к середине четверга, после чего некоторым сотрудникам было нечем себя занять, то, значит, она слишком мала. Увеличьте размер очереди на единицу и последите за результатами в течение нескольких недель.
Размеры очереди и буфера должны подвергаться поправкам на основании опыта. Поэтому не стоит слишком долго раздумывать над установлением WIP-лимита. Не задерживайте ход канбан-системы из-за того, что никак не можете договориться об идеальном WIP-лимите. Сделайте выбор! Лучше начать работу, не имея полной информации, чтобы затем на основании наблюдений внести поправки. Канбан – это эмпирический процесс.
Какой должна быть входящая очередь, если вы используете расстановку приоритетов по запросу? Как уже упоминалось в главе 4, входящая очередь команды XIT состояла из пяти элементов. Она создавалась в расчете на то, что будет достаточно велика для амортизации недельной пропускной способности, исходя из того предположения, что совещания по приоритетам будут еженедельными. Однако вскоре менеджеры продукта пришли к выводу, что совещания не очень нужны, а решения можно принимать по ситуации, как только освобождается место в очереди. Когда это случилось, мне следовало посоветовать Драгошу сократить входящую очередь с пяти позиций до одной. Я этого не сделал по неопытности. Система изменилась. Основания, на которых она выстраивалась, – тоже. Правила о размерах входящей очереди были основаны именно на прежней системе, поэтому их нужно было пересмотреть. Если бы мы так и поступили, то сокращение времени выполнения оказалось бы еще более впечатляющим.
Когда в XIT переключились на расстановку приоритетов по запросу, пополнение очереди обычно занимало около двух часов на один элемент. Можно с уверенностью сказать, что на пополнение очереди никогда не уходило более четырех часов. Однако разработчики находились далеко от менеджеров продукта. Люди, принимавшие решения по приоритетам, сидели в Редмонде, а разработчики – в Хайдарабаде. Все они официально трудились по восемь часов в день, причем время работы у них чаще всего не совпадало. Поэтому нередкими были ситуации, когда сотрудники, жившие в Индии, утром приходили на работу, завершали задачи и ждали пополнения очереди, в то время как у менеджеров продукта в США продолжался сладкий ночной сон. Следовательно, нужно было учесть возможность 16-часового ожидания пополнения элемента очереди в критических обстоятельствах. Помните, что в этом рабочем процессе бутылочным горлышком были разработчики, и, чтобы максимально увеличить пропускную способность, мы совершенно не хотели их простоя. Поэтому нужно иметь запас прочности: 16 часов – это консервативное решение, учитывая, что в среднем решение по пополнению очереди занимает всего два часа. Итак, какова будет пропускная способность за эти 16 часов? На пике производительности команда реализовывала 56 элементов за квартал, то есть менее пяти в неделю. Так что маловероятно, чтобы за 16 часов они закончили бы хоть один элемент. Таким образом, очередь из одного элемента была вполне приемлемой. А вот отсутствие очереди неприемлемо. При этом сохранялась вероятность, что команда будет простаивать, когда они закончат работу за те 16 часов, пока менеджеры продукта будут недоступны для пополнения очереди.
