Книга: Постигая Agile

Измерение и управление потоком

Измерение и управление потоком

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

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

Вы также знаете, каково это, когда работа буксует. Такое чувство, будто вы увязли в жиже и едва можете двигаться. Кажется, что вы вечно кого-то ждете, чтобы закончить создание необходимого, или принимаете решение, влияющее на работу, согласовываете карточку, либо находится еще что-нибудь, препятствующее работе, – даже если вы знаете, что никто намеренно не мешает. Вы ощущаете несогласованность и непоследовательность и тратите много времени на объяснение, почему вы ждете. Это не означает, что команда недостаточно загружена, возможно, люди выкладываются на 100 %, а может даже и перегружены. Но в то время, как план проекта говорит о том, что работа выполнена на 90 %, вам кажется, что, наоборот, еще нужно сделать 90 % работы.

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

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

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

Но откуда известно, что добавление WIP-лимита действительно увеличивает поток?

Вернемся к бережливому мышлению, которое подсказывает, что мы должны проводить измерения, а эффективный инструмент измерения потока – кумулятивная диаграмма потока[86] (cumulative flow diagram, CFD). CFD похожа на WIP-диаграмму, но имеет одно важное отличие: вместо того чтобы исчезать, выполненные рабочие элементы накапливаются в нижней полосе диаграммы. И если на WIP-диаграмме (из главы 8) полосы соответствуют состояниям в карте потока создания ценности, то CFD (и WIP-диаграмма) в этой главе имеет полосы, соответствующие столбцам на канбан-доске.

CFD в этой главе имеет дополнительные линии, показывающие среднюю частоту поступления (число рабочих элементов, ежедневно добавляемых в рабочий процесс) и среднюю емкость (общее количество рабочих элементов в рабочем процессе). CFD также может показывать среднее время производства (или время, на протяжении которого рабочий элемент остается в системе, как мы говорили о рабочих элементах в главе 8). Не все CFD имеют эти линии, однако они очень полезны для понимания потока рабочих элементов в рамках системы.

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

Рис. 9.9. Канбан-команды используют кумулятивные диаграммы потока (CFD) с полосами, которые соответствуют колонкам на канбан-доске. CFD похожа на WIP-диаграмму, за исключением того, что со временем рабочие элементы не перемещаются к концу графика, а накапливаются в полосах или линиях

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

Еще потребуются два дополнительных элемента данных, которые нужно ежедневно добавлять в диаграмму: это скорость поступления и общее количество элементов. Чтобы найти частоту ежедневного поступления, посчитайте число рабочих элементов, которые были добавлены в первый столбец. Для составления графика общего количества элементов подсчитайте общее количество рабочих элементов в каждом столбце. Каждый день добавляйте точку в CFD, соответствующую скорости поступления и общему количеству элементов, чтобы прочертить две линии в верхней части WIP-диаграммы.

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

Если посмотреть на рукописные заметки на рисунке 9.10, то видно, что мы обозначили эти ценности следующим образом: буква L используется для среднего значения общего количества элементов, греческая буква ? – для среднего значения скорости поступления (или количества рабочих элементов, добавляемых ежедневно), а W – для среднего времени производства (или среднего времени ожидания пользователями окончания работы по запросу).

Рис. 9.10. Этот пример CFD также показывает частоту поступления и усредненное количество элементов. Общий размер незавершенной работы на любой момент времени можно найти, измерив разницу между верхней частью диаграммы и верхней частью линии «Выполнено». Горизонтальная сплошная черная линия показывает время выполнения для конкретного рабочего элемента в системе. Мы пока не можем вычислить среднее время выполнения нового элемента, потому что система нестабильна – тренды общего количества элементов и скорости их поступления имеют вид наклонной линии. Это означает нестабильность

Взгляните на линию списка элементов в CFD (толстая пунктирная линия наверху). Тренд снижается; это говорит нам, что общий объем элементов со временем уменьшается, то есть много рабочих элементов вышли за пределы системы (сделаны) и никогда не возвращались. Но, посмотрев вниз, вы увидите, что скорость поступления увеличивается.

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

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

Когда система стабильна, существует простая связь между этими величинами, так называемый закон Литтла (время, затрачиваемое на выполнение полезной работы).

Эта теорема – часть теории массового обслуживания, названная в честь Джона Литтла, который впервые предложил ее в 1950-х годах и считается «отцом маркетинга». И хотя греческая буква L означает закон Литтла, не нужно быть математиком, чтобы использовать эту формулу:

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

Верно также и обратное:

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

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

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

Продолжительное время выполнения нового заказа – хороший индикатор качества проблем: Дэвид Андерсон в уже упоминавшейся книге «Канбан. Альтернативный путь в Agile» так говорит об этом:

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

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

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

Это может показаться немного абстрактным. Полезно представить, как применялась бы CFD в случае наиболее знакомой и простой системы – медицинского центра. Допустим, вам нужно несколько раз посетить врача, чтобы сдать ряд анализов и обсудить результаты. Вы заметили следующее: если встреча с доктором назначена на утро, когда прием только начинается, то вам не приходится долго ждать. Но если визит предполагается в более позднее время, то ожидание затягивается – и чем позднее время встречи, тем дольше вы ждете приема. Очевидно, что эта система нестабильна. Как использовать CFD для ее стабилизации?

Прежде всего нужно визуализировать рабочий процесс.

Допустим, каждый пришедший начинает свой визит в приемном покое. В конце концов медсестра вызывает его в один из кабинетов, где взвешивает, измеряет давление и температуру. Затем пациенты ждут приема врача. В данном медицинском центре пять процедурных и два врачебных кабинета, и они почти всегда заняты. Важно понять: в процедурных не может быть одновременно более пяти больных, а в кабинетах врача – более двух. Это WIP-лимит, введенный реальными ограничениями системы.

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

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

Давайте выясним. Начнем с построения CFD для типичного дня. Попросим персонал центра посчитать количество пациентов, входящих в медицинский центр каждые 15 минут. Это покажет скорость прибытия – в буквальном смысле количество прибывших в центр пациентов. И мы можем рассчитать список для каждого 15-минутного интервала путем подсчета общего количества пациентов в приемном покое и пяти процедурных кабинетах. Каждый раз, когда кто-то приходит, добавляется стикер в первую колонку на канбан-доске. Когда пациент переходит из приемного покоя в процедурную, стикер перемещают во вторую колонку. А если пациент уже зашел к врачу, то стикер сдвигается в третью колонку. После того как врач закончил работу с пациентом, стикер удаляют с доски. Сотрудники центра могут записать количество стикеров в колонках для каждого 15-минутного интервала.

Теперь у них есть все данные, которые нужны для построения CFD.

Рис. 9.12. Эта CFD показывает поток пациентов через медицинский центр. В течение дня приемный покой все больше заполняется людьми. Догадываетесь ли вы, почему полоска для третьего столбца исчезает между 12:15 и 13:00?

Эта система нестабильна. Скорость прибытия пациентов стабильна, потому что администраторы сами назначают время приема пациентов, а те, в свою очередь, приходят с постоянной скоростью. Администраторы не хотят задерживаться на работе. Поэтому прекращают запись после 16:00. Люди попадают к врачу позже назначенного времени, но тенденция скорости прибытия плоская, поэтому она должна быть довольно постоянной на протяжении всего дня.

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

Первое, что нужно сделать, – стабилизировать систему. Инструментом для этого послужит WIP-лимит. Сотрудники будут использовать канбан-практику эволюционного развития и экспериментальное улучшение путем определения WIP-лимита в качестве отправной точки. Посмотрев на данные, каждый решает установить для приемного покоя WIP-лимит, равный 6. Но это возможно при одном условии: врачи должны согласиться, что если там собирается шесть пациентов, то администраторы должны позвонить тем, кому назначено позднее, и попросить их перенести встречу (стараясь найти такое время, чтобы не нанести ущерба здоровью пациента). Кроме того, администраторы предложат ожидающим добровольно перенести визит, обещая при этом выбрать приоритетное для них время. Этой новой политики нужно четко придерживаться. Они будут делать это, добавляя WIP-лимит на канбан-доске, а также размещая уведомления на информационной стойке, давая понять, что такова теперь политика центра.

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

И это работает! Персонал обнаружил, что, как только был введен WIP-лимит, появилась возможность записывать пациентов и после 16:00. Теперь их успеют обслужить до 18:00. Они могут планировать запись на 17:40, а пациентов с более серьезными проблемами – после 16:40 (и они придерживаются этой политики). Безусловно, если кто-то обратится в клинику с серьезной проблемой, то врач осмотрит этого пациента (или отправит в отделение неотложной помощи). Но это редкое исключение, потому что персонал клиники – умные и ответственные люди, способные принимать решения в каждом конкретном случае. Пациенты теперь выглядят намного счастливее, потому что им не приходится долго ждать.

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

Сотрудники офиса отнеслись к канбан-практике улучшения очень серьезно. И экспериментальным путем пришли к интересному выводу: они обнаружили, что после введения WIP-лимитов появилась возможность контролировать время ожидания пациентом врачебного приема. Если на каждый час планировалось много визитов, то четырем-пяти пациентам пришлось бы долго ждать. А если запись сокращалась, то перед кабинетом врача сидели бы только два-три пациента, и ждать им пришлось бы меньше. Впервые они почувствовали, что действительно контролируют систему, которая в прошлом вызывала головную боль.

Так что же происходит?

Сотрудники клиники обнаружили существование в стабильной системе связи между списком приема (количеством), временем обслуживания и скоростью поступления. Например, если персонал каждый час записывает 11 пациентов (так как скорость поступления ? равна 1 часу) и среднее количество в течение дня превышает семь пациентов (так как L равно 7), то закон Литтла говорит нам, что среднее время ожидания пациентами своего приема составит:

Но вдруг после ряда экспериментов они обнаружат, что планирование 10 пациентов, прибывающих каждый час, снижает список до четырех пациентов? В час пик все процедурные переполнены, но большую часть времени один пациент находится в приемном покое, один ожидает приема врача в процедурной комнате и двое – на приеме у врача:

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

Это работает, потому что закон Литтла говорит нам, что в стабильной системе на время обслуживания пациента влияет две вещи: очередь и скорость прибытия. А WIP-лимиты позволяют контролировать одну из них. При добавлении WIP-лимита на канбан-доску вы можете уменьшить неравномерность, которая приводит к нагромождению в очереди. Это дает возможность сократить время обслуживания за счет снижения скорости поступления (например, удерживая работы в бэклоге до тех пор, пока команда занята выполнением текущего задания, как делают scrum-команды, или уменьшая число пациентов, записанных в течение каждого часа.

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

Теперь рассмотрим пример, приближенный к реальной жизни. Допустим, каждые три недели ваша команда вязнет в работе по выпуску релиза.

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

Рис. 9.14. Мы вернулись к области WIP на диаграмме, чтобы лучше рассмотреть стабильность системы. Эта диаграмма показывает: скорость прибытия постоянна, но среднее общее количество запросов со временем увеличивается, что означает нестабильность системы

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

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

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

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

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

Мы видим, что общее количество запросов растет, а это означает нестабильность системы и остановку потока работы через систему. Неудивительно, что команда чувствует, как вязнет.

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

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

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

Рис. 9.16. Когда вы находите удачное значение для WIP-лимита, в столбце больше не хранится работа, а полоски WIP-области на диаграмме не накапливают работу со временем. Как это выглядит на диаграмме? Как вы думаете, будет ли диаграмма CFD визуализировать эту конкретную проблему лучше, чем WIP-область на диаграмме?

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

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

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

Но что если работа по поддержанию занимает все места в очереди? Как тогда будет совершаться разработка?

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

Теперь руководство имеет гораздо более точную информацию об успехах команды. Это один из принципов agile-разработки программного обеспечения, описанный в главе 3: работающее программное обеспечение – это главная мера прогресса. Раньше казалось, что перегруженная команда способна производить программное обеспечение и поддерживать его. Не всем было очевидно, что дополнительная нагрузка вынуждает ее снижать качество ПО и приводит к тому, что его трудно поддерживать, а также потенциально является причиной некоторых случаев, когда поддержка необходима. Теперь, когда команда сократила поставку программного обеспечения, руководитель может точнее оценить прогресс. Это мешает ему делать вид, будто люди могут выполнить гораздо больше того, что в человеческих силах. Если он хочет получить больше ПО, то должен либо поставить это в приоритет над поддержкой, либо нанять больше сотрудников. Но намного легче просто обвинять команду.

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

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

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

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

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

Именно поэтому многие люди с удивлением реагируют на то, что их руководитель согласился на WIP-лимит: они испытывают облегчение.

До введения WIP-лимита всем казалось, что дополнительная работа «просачивается» в спринт, и команда вынуждена была полагаться на временной резерв, чтобы ее выполнить. Она всегда начинала спринт при условии, что определено только 70 % работы, потому что нетерпеливые руководители и пользователи будут искать возможность втиснуть в последнюю минуту еще 30 % (а то и все 40 % или даже больше) изменений и срочных просьб.

После введения WIP-лимита (и, что не менее важно, согласия на его поддержание) дополнительные просьбы по-прежнему будут появляться, но теперь команда не обязана выполнять всю незапланированную работу. Вместо этого из новых задач формируется очередь. Давление на команду уменьшается, потому что объем работ будет ограничен и не будет накапливаться. Она может управлять потоком (возможно, используя CFD), так как знает, что WIP-лимит гарантирует необходимое время.

Именно поэтому многие канбан-команды вводят WIP-лимиты в каждом столбце канбан-доски.

Это помогает команде контролировать поток на каждом шаге разработки. Даже для столбца «Готово к выпуску» тоже есть WIP-лимит. Если выполненной работы накапливается слишком много, то команда может заниматься другими делами, чтобы подготовиться к следующему релизу, – и теперь она располагает большим объемом информации, чтобы отрегулировать ритмичность поставок в будущем за счет сокращения времени между релизами.

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

Рис. 9.17. Введение WIP-лимитов в каждом столбце канбан-доски помогает команде максимизировать поток на протяжении всего проекта

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

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

А что если вы попросите об этом же неэффективную команду с типичным водопадным процессом? Велика вероятность того, что у них раздробленное видение (мы писали об этом в главе 2). Наверняка каждый расскажет, как выполняет свою ежедневную работу: разработчики будут писать о кодировании, тестировщики – о тестировании, бизнес-аналитики – о сборе требований и т. д. Руководитель проекта может иметь более широкую перспективу, потому что должен знать роль каждого в создании плана проекта, поэтому, вероятно, включит в описание работу всей команды. Но также не исключено, что он просто опишет шаги, которые необходимы для планирования и отслеживания проекта.

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

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

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

Сложные процессы и неписаные правила обычно возникают со временем и особенно распространены в командах с раздробленным видением. Усложнение процессов контроля изменений может произойти, потому что для бизнес-аналитика проблематично поддерживать большое количество изменений в последнюю минуту и он громко и часто возмущается при всей команде, что «наше программное обеспечение не удовлетворяет потребностям конкретного пользователя». Он может усложнить процесс, чтобы контролировать границы изменений и убедиться, что существуют бумажные документы, благодаря которым можно спасти свою шкуру, если в дальнейшем кто-нибудь решит изменить мнение. Трудно винить бизнес-аналитика в создании оборонительной бюрократии. Это может оказаться единственно возможным способом контролировать спецификацию, за которую он несет ответственность.

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

Оглавление книги