Постигая Agile Грин Дженнифер
Команды разработки программного обеспечения занимаются совершенствованием процессов с тех пор, как люди начали создавать ПО. В идеале совершенствование процессов работает очень хорошо: команда получает поддержку со стороны руководства, проводит замеры, определяет проблемы, улучшает орудия труда, а затем снова начинает выявлять то, что можно усовершенствовать. В конце концов улучшение всей организации в первую очередь позволяет создавать повторяемые процессы, затем управлять ими и наконец взять под статистический контроль. Уже многие компании заявили о больших успехах в этой области.
Если вы разработчик, уже переживший типичную попытку усовершенствования процессов, то, скорее всего, поспешите отложить книгу в сторону, прочитав это описание.
Термин «усовершенствование процесса» часто вызывает в воображении образ героя комиксов по имени Дилберт. Он ассоциируется с бесконечными совещаниями и процессами, полными технологической документации, потому что типичное улучшение процесса сильно отличается от идеального. В случае типичного процесса совершенствования крупная компания решает, что их программисты производят программное обеспечение недостаточно эффективно (или что они нуждаются в сертификации процесса для заключения контрактов либо для маркетинговых целей), поэтому нанимают консалтинговые компании, тратят много времени (и денег) на создание блок-схем существующих и желаемых процессов развития и обучают команды использовать новые процессы. Затем команды тратят около 10 минут, чтобы опробовать один из новых процессов, выясняют, что он им не подходит, и отказываются от него. Но поскольку топ-менеджеры проспонсировали весь процесс усовершенствования усилий, команда вынуждена делать вид, что использует нововведения, поэтому усердно заполняет любые документы по новым требованиям (например, область применения документа и техническое задание) и создает обязательные артефакты (протоколы собраний для просмотра кода и отчеты о тестировании, которые, как правило, пусты и шаблонны). Для каждого успешного процесса совершенствования усилий (их несколько) есть много ничего не дающих или вовсе неудачных попыток приложения усилий, побочный продукт которых – глубокая неприязнь к термину «улучшение процесса».
Существует одно большое отличие между Канбаном и традиционным процессом улучшения. В последнем случае решения, как правило, спонсируются высшим менеджментом, готовятся комитетом (например, группами процессов разработки программного обеспечения) и доводятся до сведения команд через их непосредственных руководителей. В Канбане улучшение остается в руках команды. Именно поэтому agile-команды добились успеха в применении этого метода. Члены команды самостоятельно находят проблемы в рабочем процессе, предлагают свои варианты улучшения, оценивают результаты и берут на себя ответственность за собственные стандарты.
Как Канбан помогает команде улучшить собственный процесс?
Первый этап в улучшении процесса – это понимание того, как в настоящее время работает команда, и практика визуализации в Канбане позволяет это сделать. Звучит просто, но все гораздо сложнее, чем кажется, – многие традиционные процессы совершенствования идут неправильно.
Представьте, что вы программист, а ваш руководитель приходит к вам и спрашивает: «Как ты ведешь разработку программного обеспечения?» Ваша задача – написать, как вы делаете свою работу. Поэтому вы запускаете Visio (Omnigraffie или другое приложение диаграмм) и начинаете создавать блок-схему, показывающую все то, что вы делаете каждый день. Иногда будет обнаруживаться, что замечательные практики, такие как обзор кода (или тестирование кода, прежде чем его выпустить, и т. д.), вы действительно применяете, но не каждый раз. Полагая, что это надо делать всегда, и вы наверняка иногда так делаете, вы добавляете этот элемент в свою схему. Такова человеческая природа. Легко найти оправдание собственным поступкам – если это хорошая идея, значит, можно создать уверенность в том, что все это время вы применяете такие практики.
Это уничтожает процесс совершенствования, потому что скрывает реальную проблему.
Если этап, который вы добавили к вашей схеме, – хорошая идея, то теперь это выглядит так, будто вы уже это делаете. Никто и не подумает спросить: «Почему мы этого не делаем?» Зачем? Ты уже так работаешь! Что если есть причина, по которой вы не делаете это каждый раз, – скажем, обзор кода всегда отменялся, потому что его всегда проводят менеджеры команды, а они всегда заняты? Вы никогда не обнаружите и не попытаетесь исправить основную проблему, потому что каждый будет смотреть на диаграмму, видеть блок, касающийся обзора кода, и искать точки улучшений процесса где-нибудь в другом месте.
В Канбане визуализация означает запись именно того, что делает команда. Недостатки и тому подобные вещи не приукрашиваются. Это часть бережливого мышления: канбан-команда принимает lean-принцип. Чтобы видеть картину целиком. Правильное мышление не позволяет команде возиться с визуализацией рабочего процесса, потому что это помешало бы увидеть картину целиком. Ценность принимать решения как можно позже также важна: у вас еще нет всей информации о том, как разрабатывать программное обеспечение, поэтому остается последний ответственный момент, чтобы принять решение, как вы измените его.
Наряду с другими гибкими методологиями канбан-практики помогают вам заполучить lean-мировоззрение и принять бережливое мышление. Чем точнее и объективнее вы визуализируете рабочий процесс, тем быстрее примете такие ценности, как видеть целое и принимать решения как можно позже.
Так как же команды визуализируют рабочий процесс?
Канбан-доска – это инструмент, который команды используют для визуализации рабочего процесса. (Заглавная буква «К» используется при упоминании метода, со строчной буквы «к» пишется название доски.) Канбан-доска похожа на доску задач Scrum: обычно там есть колонки и стикеры. (Чаще всего на канбан-доске встречаются стикеры, а не учетные карточки.)
Существует три очень важных различия между доской задач и канбан-доской. Вы уже знаете о первом из них: канбан-доски содержат только истории и не показывают задачи. Еще одно состоит в том, что столбцы в канбан-досках обычно могут быть разными у различных команд. Наконец, на канбан-досках могут устанавливаться лимиты на объем работ в колонке. В дальнейшем мы поговорим об этих ограничениях, а сейчас сосредоточимся на самих колонках и том, как команды, использующие Канбан, часто имеют разные столбцы на канбан-досках. Одна доска команды может иметь колонки «сделать», «в процессе» и «сделано». А другая – совершенно иные колонки.
Когда команда хочет внедрить Канбан, она прежде всего визуализирует рабочий процесс на канбан-доске. Например, одна из первых канбан-досок в книге Дэвида Андерсона «Канбан. Альтернативный путь в Agile» имеет следующие столбцы: «входящая очередь», «анализ» (в процессе, готово), «готово к разработке», «разработка» (в процессе, готово), «готово к сборке», «тестирование» и «готово к релизу». Эта доска будет использоваться командой, которая следует за процессом, где каждая функция проходит через анализ, развитие, сборку и тестирование. Поэтому она может начать c такого варианта канбан-доски, как показано на рисунке 9.1, на которой есть колонки с текущими рабочими элементами.
Рис. 9.1. Пример того, как рабочие элементы, написанные на бумажках, перемещаются по канбан-доске. Дэвид Андерсон в своей книге «Канбан. Альтернативный путь в Agile» использовал именно такой вариант доски, но названия колонок могут отличаться в зависимости от того, как члены команды выполняют свою работу
Команда будет использовать канбан-доску, так же как Scrum-команды – доски задач. Канбан-команда проводит встречи (обычно ежедневные), которые называются «прогулка вдоль канбан-доски» (walking the board). На них обсуждается состояние каждого элемента на доске. Она должна отражать текущее состояние системы: каждый элемент, завершающий текущий этап, должен быть перемещен в следующую колонку. Но если этого еще не сделано, то команда знает, что во время встречи доска будет обновлена.
Важно понимать, что канбан-доска визуализирует основной рабочий процесс и процесс использования. Любые примеры, приведенные здесь и в других текстах (в книге «Канбан. Альтернативный путь в Agile» Дэвида Андерсона), – это лишь примеры из реальных контекстов. Вообще не стоит копировать канбан-доску, лучше разработать свою, изучая собственный рабочий процесс и визуализируя его. Копирование существующего процесса без привязки к конкретному контексту противоречит эволюционному подходу Канбана. Если метод требует начать с того, что сейчас делаете именно вы, то не стоит копировать действия других людей[85].
Вернемся к примеру из главы 8, в котором команда пыталась справиться с очень длительными сроками и разочарованными клиентами. Если вернуться к изначальному описанию команды, то изложение их рабочего процесса, которое менеджер проекта показывал руководству, будет таким:
1. Команда получает запрос от пользователя.
2. Руководитель проекта намечает функционал для следующего релиза.
3. Команда разрабатывает функционал.
4. Команда тестирует функционал.
5. Менеджер проекта проводит приемку.
6. Функционал реализован и включен в следующий релиз.
Пункты в главе 8 – это один из способов поддержания связи в рабочем процессе. И этот пронумерованный список тоже, но визуализация более эффективный инструмент для выполнения этой задачи.
Рисунок 9.2 показывает, что вариант рабочего процесса менеджера проекта, который можно назвать «счастливый путь», выглядит так, как показано на канбан-доске.
Рис. 9.2. Здесь показано, как люди воспринимают Канбан в ходе работы над проектом
Но это не то, что происходит в реальной жизни. В главе 8 команда использовала пять «почему», чтобы узнать больше о рабочих процессах. В дальнейшем список выглядел так:
1. Команда получает запрос от пользователя.
2. Менеджер проекта намечает функции на следующий трехмесячный релиз.
3. Команда собирает функцию.
4. Команда тестирует функцию.
5. Менеджер проекта проверяет прохождение тестирования.
6. Менеджер проекта планирует показ демоверсии высшему руководству.
7. Если топ-менеджер хочет, чтобы команда внесла изменения, то руководитель проекта проводит анализ влияния изменений, функция возвращается в пункт 1 и по порядку двигается к пункту 8.
8. Функция выполнена и включена в следующий релиз.
Теперь мы знаем, что есть дополнительный шаг, когда старшие менеджеры при необходимости могут вносить изменения в функции и переносить их в будущие релизы, хотя команда считает функции готовыми.
Мы будем менять канбан-доску, чтобы представить это нагляднее, добавляя колонки «комментарии менеджера» для тех функций, которые ожидают старшие менеджеры в демоверсии.
Рис. 9.3. Эта канбан-доска представляет более точную картину того, как протекает проект
Теперь у нас есть более точная визуализация рабочего процесса в команде. Если на канбан-доске видно все течение релиза, то проблема становится очевидной. Рабочие элементы накапливаются в столбце «приемка руководством» и хранятся там до окончания релиза, как показано на рисунке 9.4.
Рис. 9.4. Когда вы используете канбан-доску для визуализации рабочего процесса, проблемы, возникающие из-за неравномерности, легче обнаружить
А как насчет рабочих элементов, которые были отнесены к будущему релизу в связи с доработками, которые инициированы менеджерами? Мы особенно заботимся о таких элементах, потому что из-за них некоторые пользователи ушли к конкурентам.
Рис. 9.5. Канбан-доска делает потери более очевидными, когда вы видите, что в течение рабочего процесса они встречаются несколько раз
По некоторым из элементов работа уже началась и должна продолжаться. Когда рабочие элементы требуют доработки уже после проверки менеджером, они возвращаются в начало процесса. Давайте убедимся, что они представлены на канбан-доске, – мы добавим столбец в начале пути, назовем его «На доработку» и передвинем стикеры влево (ставим маленькую точку на каждом стикере, чтобы сразу обнаружить, если они попадутся во второй раз).
Это довольно хорошая визуализация процесса, которому следует команда. Теперь мы можем точно видеть, что не так с проектом и почему ситуация ухудшалась. Некоторые члены команды, наверное, догадывались, что происходит, но теперь это ясно любому, кто смотрит на доску. И еще важнее, что это объективное свидетельство того, что способ, которым старшие менеджеры проводят обзор функций, – это основная причина проблем со сроками.
Мы никогда не стали бы запускать серверы в компьютерных залах на полную мощность – почему мы не усвоили этот урок при разработке программного обеспечения?
Мэри и Том Поппендик. Lean Software Development: An Agile Toolkit
Только команда может делать так много работы. Мы узнали об этом при изучении Scrum и ХР, и это важная часть бережливого мышления. Когда команда соглашается сделать больше того, на что способна, случаются неприятности. Она либо игнорирует некоторые виды работ, некачественно создавая продукт, либо работает в неустойчивом темпе, что в будущих релизах обойдется очень дорого. Иногда не сразу становится очевидно, что команда взяла на себя больше обязательств, чем может выполнить: каждый отдельный дедлайн выглядит разумным, но если предполагается, что все работают в многозадачном режиме в нескольких проектах или с несколькими элементами одновременно, то команда постепенно начинает испытывать перегрузки и требуются дополнительные усилия для переключения с одной задачи на другую. А это приводит к потере до 50 % производительности.
Визуализация рабочего процесса позволяет команде распознать перегрузку. Это первый шаг к устранению проблемы. Неравномерность и перегрузки, о которых мы узнали в главе 8, проявляются на канбан-доске, когда стикеры собираются в одном столбце. К счастью, теория массового обслуживания не только предупреждает нас о проблеме, но и предлагает способ ее исправить. После выявления неравномерностей в рабочем процессе мы можем управлять объемом работ во всей системе, поставив жесткое ограничение на выполнение незавершенной задачи. Такая канбан-практика называется ограничение на выполнение незавершенных работ (limit work in progress, WIP-лимит).
Ограничение на выполнение незавершенных работ означает установление ограничения на количество рабочих элементов, которые могут находиться на разных стадиях реализации проекта. Как правило, большинство людей сосредоточены на том, чтобы как можно скорее переместить рабочие элементы внутри процесса. Для одного элемента этот рабочий процесс – линейный: если вы программист и закончили написание кода для функционала, а ваш рабочий процесс требует, чтобы вы еще и протестировали его, то легко начать ненужную спешку, потому что это последний этап вашей работы.
Но что делать, если команда тестировщиков уже работает над несколькими функциями и не может одновременно проверить их? Не имеет смысла немедленно браться за новую функцию, если потом придется ждать, чтобы кто-нибудь ее протестировал. Это приведет к перегрузке команды тестировщиков. Так что же делать?
Для этого Канбан возвращается к бережливому мышлению – в частности, к принципу вариантного мышления, о котором говорилось в главе 8. Одна из причин, почему канбан-команда использует канбан-доску, – это возможность увидеть на ней все варианты. Если вы как разработчик только что закончили создавать архитектуру нового функционала, то легко предположить, что теперь вы возьметесь за код. Но работа над кодом для данного функционала – это возможность, а не обязательство. Глядя на канбан-доску, вы видите много стикеров, с которыми можно дальше работать. Вероятно, есть другие стикеры, сообщающие о необходимости разработки нового функционала, или столбец с ошибками, найденными во время тестирования функционала и ждущими исправления. Как правило, у вас большой выбор. Какой вариант вы предпочтете?
Установление WIP-лимитов на этапы в рабочем процессе подразумевает ограничение количества элементов работы, допустимых на этом этапе. Это облегчает команде выбор элементов работы, позволяет избежать перегрузки и способствует равномерному и максимально эффективному протеканию рабочего процесса в ходе разработки функционала. После ее завершения вы видите, что взять в разработку новый функционал невозможно из-за ограничений лимита. Тогда вы смотрите на другие возможности применения своих навыков, имеющиеся на доске, и работаете с ними – и команда тестировщиков не будет перегружена. (Представляете себе, как это может сократить среднее время разработки функционала? Если да, то вы начали приобретать навык системного мышления!)
Давайте вернемся к команде, которая использует пять «почему», чтобы найти причину проблемы во времени, отведенном на выполнение заказа. После того как мы создали для них канбан-доску, определилась перегрузка: стикеры начали накапливаться в колонке «приемка руководством». Поэтому, чтобы ограничить объем выполняемых работ для этой команды, мы просто нашли способ ограничить количество скапливающихся элементов до того, как менеджеры проведут сессию приемки.
В Канбан, узнав о такой проблеме рабочего процесса, как эта, вы устанавливаете WIP-лимит (или работаете с ограничением на выполнение незавершенных работ). Для этого команда должна встретиться с руководством, чтобы убедить всех принять новые правила. Новая политика устанавливает WIP-лимит, подразумевающий, что в столбце «приемка руководством» может накапливаться только определенное количество элементов работы. Канбан-доска и подсчет времени на выполнение заказа дают команде и руководителю проекта достаточно объективных доказательств, чтобы убедить менеджера согласиться с этим.
Когда мы устанавливаем WIP-лимит на столбец, он перестает быть местом, где скапливается масса рабочих элементов. Вместо этого образуется очередь, или стадия в рабочем процессе, где управление идет плавным и упорядоченным образом.
Не существует жесткого правила, устанавливающего размер WIP-лимита. Команда использует эволюционный подход к этому элементу. Обычно исходя из здравого смысла экспериментальным путем находят оптимальный вариант. В нашей команде каждый релиз, как правило, имеет 30 элементов функционала. Чтобы старшие менеджеры чувствовали себя комфортно, они могут встретиться три раза на протяжении релиза, поэтому мы выберем WIP-лимит, ограниченный десятью элементами в колонке «приемка руководством», как это показано на рисунке 9.6.
Рис. 9.6. Число 10 в столбце «Приемка руководством» – это его WIP-лимит
Что происходит, когда в колонку «приемка руководством» добавляется десятый элемент работы? Достигнув лимита, команда больше ничего не помещает в этот столбец. Вероятно, для нее найдется и другая работа. Если разработка закончена, то она поможет тестировщикам. Не исключено, что есть технический долг, который можно устранить, – если на доске нет стикеров с соответствующими элементами, то таких элементов работы не должно быть на самом деле. Единственное, чего они не делают, – не «засовывают» в колонку «Приемка руководством» дополнительные элементы работы. Для этого существует соглашение с топ-менеджерами: как только колонка достигнет WIP-лимита, менеджеры будут проводить обзоры и работа будет накапливаться до тех пор, пока это не произойдет.
Рис. 9.7. Когда колонка достигает своего WIP-лимита, в нее больше не добавляются стикеры, даже если это выполненная работа. Команда переносит внимание на рабочие элементы в других столбцах, которые еще не достигли WIP-лимита
Как только менеджеры выполняют свое обещание, проводят обзор и расчищают «завалы», работа движется вперед. WIP-лимит заставляет их давать обратную связь гораздо раньше, поэтому команда может немедленно внести необходимые изменения. Если рабочий элемент натыкается на препятствия, то менеджеры узнают об этом в начале проекта, а не в конце. Это наносит меньший вред команде, потому что ей не приходится выполнять много ненужной работы, которая затем может оказаться в колонке «На доработку». Сделанная работа немедленно приобретает ценность, в отличие от той, что находится в колонке «На доработку» до тех пор, пока ею не заинтересуется компания (или пока разозленные клиенты не уйдут к конкуренту).
Это эффективно, потому что цикл приемки менеджментом и изменения, внесенные командой, замыкаются в петле обратной связи. При этом, если петля обратной связи слишком длинная – например, равняется длине всего релиза, – то информация, попадающая назад в проект, становится разрушительной, потому что команде приходится пересматривать массу уже проделанной работы. Это приводит к потерям.
Добавление WIP-лимита устраняет причины перегрузки, среднее время рабочего элемента в системе получается намного короче. Теперь в течение проекта менеджеры несколько раз проведут приемку, что позволит команде раньше внести коррективы. И менеджеры смогут использовать эту информацию для более раннего изменения приоритетов, поэтому ценная работа не пойдет в потери.
Более того, теперь команда и менеджеры могут контролировать длину петли обратной связи. Например, если руководители считают, что информация является ценной, и они могут согласиться уменьшить WIP-лимит до шести элементов, это приведет к более частым встречам и даст команде более раннюю обратную связь.
Нет, если команда тратит больше времени на проведение совещаний и обратную связь, чем на выполнение самой работы. Как и любым инструментом, WIP-лимитами и петлями обратной связи можно злоупотреблять. Когда система имеет слишком короткую петлю обратной связи, она может попасть в состояние, которое называется пробуксовкой. Это случается, когда слишком много информации попадает обратно в систему и не хватает времени для ее обработки, а тем временем поступает следующая партия данных.
Визуализация рабочего процесса при помощи канбан-доски позволяет команде увидеть петли обратной связи и экспериментировать с WIP-лимитами, чтобы найти оптимальную длину обратной связи. Это обеспечивает регулярную обратную связь, причем команда успевает ответить на замечания прежде, чем придет следующая партия.
Нужно избегать при этом многократной отправки одних и тех же элементов через цикл обратной связи, потому что это засоряет систему. Но Канбан помогает заметить и это. Например, когда менеджеры дают обратную связь команде и просят переделать, работа отправляется назад в бэклог. Члену команды приходится перемещать стикер с задачей в колонку с более ранним этапом. Команда может отслеживать стикеры, которые были смещены назад, если поставит на них точку или любой другой знак – явный показатель того, что петля обратной связи для этой функции будет повторяться. Когда функция возвращается через рабочий процесс, она в итоге снова окажется в столбце «Приемка руководством» и заполнит собой одно место среди WIP-лимитов. Это приводит к эффекту засорения петли обратной связи.
Рис. 9.8. Добавление дополнительных столбцов на канбан-доску – и предотвращение попадания множества стикеров обратно в предыдущие колонки из-за их пробуксовки – дает команде больший контроль над процессом
Команда может избежать данной проблемы, удалив дополнительную петлю из рабочего процесса, сделав ее более линейной для большинства элементов. Что если команда сможет убедить менеджеров согласиться на единственный этап приемки руководством с выбором тех из элементов, которые надо переделать? Раз менеджеры доверяют команде принимать их обратную связь для большинства элементов и не требуют их повторной проверки руководством, прежде чем функционал будет выпущен, команда сможет добавлять дополнительную разработку и этап тестирования после приемки.
Этот процесс на канбан-доске выглядит длиннее. Но поскольку мы использовали объективные данные, полученные в результате измерения времени на освоение новой продукции и экспериментальные данные с WIP-лимитами, чтобы развивать рабочий процесс, как в нашем примере, то мы можем с уверенностью утверждать, что так действительно быстрее. И мы продолжим проводить измерение времени на освоение новой продукции и визуализировать рабочий процесс, чтобы доказать команде и менеджерам: несмотря на добавление нескольких этапов, производство каждой функции и включение ее в релиз протекают быстрее. Но эти измерения полезны для дальнейшего усовершенствования проекта и убеждения менеджеров в том, что он улучшается, а команде все это, скорее всего, не потребуется. Ее убедят результаты, потому что после устранения неравномерной работы и перегрузок проект явно станет продвигаться быстрее.
Ключевые моментыКанбан – это метод, улучшающий процесс разработки программного обеспечения и командной работы, основанный на lean-мировоззрении. Канбан-команды начинают с текущей работы. Они оценивают целиком реальную действительность и со временем проводят постепенные эволюционные изменения системы.
Канбан-практика развивать совместно и улучшать экспериментально подразумевает проведение измерений, постепенное улучшение, а затем подтверждение того, что работа включала эти измерения.
Каждая команда имеет систему для производства программного обеспечения (независимо от того, осознает ли она это), и идея системного мышления, принадлежащая Lean, подразумевает оказание помощи команде в понимании этой системы.
Канбан-доска – это способ визуализации рабочего процесса команды.
Канбан-доска разделена на столбцы, которые представляют каждый этап рабочего процесса. Рабочие элементы написаны на стикерах и распределены по колонкам. По мере продвижения по системе они перемещаются из столбца в столбец.
Канбан-доска использует рабочие элементы, а не задачи, потому что Канбан – это не система управления проектами.
Когда канбан-команды вводят лимит на выполнение незавершенных работ (WIP-лимит), они добавляют цифру в колонку на доске, которая указывает на максимальное число рабочих элементов, разрешенных на этой стадии рабочего процесса.
Канбан-команды работают со своими пользователями, менеджерами и другими заинтересованными сторонами, чтобы убедиться: все согласны с тем, чтобы команда сосредоточила свои усилия на другой части проекта, когда количество рабочих элементов в колонке достигает лимита, и не пытаться ничего вносить в нее сверх того.
Измерение и управление потоком
Команды продолжают поставлять функционал, они выявляют проблемы рабочего процесса и корректируют 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 означает закон Литтла, не нужно быть математиком, чтобы использовать эту формулу:
L = W .
В переводе на обычный язык это означает, что если у вас есть стабильный рабочий процесс, то средний список всегда равен средней скорости поступления, умноженной на среднее время, необходимое для выполнения нового заказа. Это математический закон: если доказано и если система стабильна, это всегда верно.
Верно также и обратное:
L = W .
Если вы знаете среднее количество и среднюю скорость поступления, то можете рассчитать среднее время выполнения нового заказа. Вычислить среднее количество и скорость поступления довольно просто: каждый день записывайте на канбан-доску общее количество рабочих элементов, а также число, которое было добавлено в первую колонку в тот же день. На нашей CFD они указаны тонкими прерывистыми или пунктирными линиями.
Если ваша система работает стабильно, то через некоторое время вы увидите, что средний ежедневный список и ежедневная скорость поступления выглядят как толстые прямые линии. Разделите средний список на среднюю скорость поступления, и вы получите время на выполнение нового заказа.
Задумайтесь над этим. Время – один из лучших способов измерения уровня разочарования пользователей: быстрая доставка обрадует их, а затягивание сроков поставки вызовет рост недовольства.
Продолжительное время выполнения нового заказа – хороший индикатор качества проблем: Дэвид Андерсон в уже упоминавшейся книге «Канбан. Альтернативный путь в Agile» так говорит об этом:
Похоже, что увеличение времени выполнения оборачивается существенно худшим качеством. В нашем случае увеличение среднего времени выполнения в 6,5 раза повлекло за собой более чем тридцатикратное увеличение первичных ошибок. Более долгое время выполнения связано с увеличением количества незавершенных задач.
Ваше время на выполнение нового заказа полностью определяется скоростью поступления рабочих элементов в систему и протекания по ней – и 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), то закон Литтла говорит нам, что среднее время ожидания пациентами своего приема составит:
W = L = 7 пациентов (11 часов) = 0,63 часа = 37 минут.
Но вдруг после ряда экспериментов они обнаружат, что планирование 10 пациентов, прибывающих каждый час, снижает список до четырех пациентов? В час пик все процедурные переполнены, но большую часть времени один пациент находится в приемном покое, один ожидает приема врача в процедурной комнате и двое – на приеме у врача:
W = 4 пациента (10 пациентов каждый час) = 0,4 часа = 24 минуты.
При помощи канбан-доски, 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-лимитов – это стратегия выбора, и работает она только потому, что каждый соблюдает соглашение не проталкивать дополнительную работу, если очередь достигла своего предела. Фиксация договоренностей (особенно если они находятся на видном месте, как канбан-доска) помогает убедиться в том, что каждый согласен с ними, после того как они записаны. Команда может указывать на записанные правила каждый раз, когда ретивый менеджер или пользователь пытается протолкнуть дополнительную работу в очередь. Это дает прочную основу, когда нужно убрать какой-нибудь элемент из очереди, чтобы освободить место для срочного запроса. Команде гораздо проще обсуждать это, если менеджер или пользователь уже согласны со стратегией, которая дает ясное понимание вещей.
Эмерджентное поведение с Канбаном
Чем сильнее вы сожмете кулак, Таркин, тем больше звездных систем ускользнет сквозь ваши пальцы.
Принцесса Лея
Вспомним пример с медицинским центром, приведенный выше. Если бы вы попросили команду, которой руководит менеджер с командно-административным стилем управления, помочь персоналу улучшить процессы, то что бы произошло? Первым делом оценили бы, сколько времени врач тратит на каждого пациента. Это потребовало бы вовлечения врачей, медсестер и сотрудников клиники, но позволило бы руководителям проекта взять под контроль систему, создать подробное описание всех ресурсов (процедурных комнат, врачей и медсестер) и на микроуровне управлять каждым аспектом практики.
Такой способ успокоил бы всех, но, к сожалению, он неэффективен. Врачи учились лечить, а не оценивать. Руководители проекта могли бы придумать идеальное расписание, но более вероятно, что они создадут нереальное расписание, потому что врачи дадут им скудные данные. Именно поэтому Канбан смотрит на всю систему в совокупности. Вместо попыток заниматься микроменеджментом любой небольшой деятельности команда использует системы мышления Канбан, чтобы понять, измерить и постепенно совершенствовать систему в целом. Принимается тот факт, что отдельные элементы работы могут меняться, но система в целом действует предсказуемо, когда потери, неравномерность и излишек (муда, мура и мури) снижаются.
Когда команда использует Канбан, чтобы постепенно улучшить процесс сборки программного обеспечения, зачастую начинает меняться и вся компания. Рассмотрим пример компании, пытающейся сократить время выполнения задачи. До попытки команды использовать Канбан менеджеры и пользователи ругали ее за отсутствие немедленной реакции на запросы пользователей. В ответ команда создала планы проекта, которые «доказали», что ничего не произошло. Это привело к конфликту и негативным эмоциям.
Канбан помог решить основную проблему. Команда использовала метод пяти «почему», чтобы найти причину удлинения времени выполнения задач, и ввела WIP-лимиты для исправления ошибки.
Но как это решило проблему? Давайте вернемся к первым двум канбан-практикам, о которых говорилось в этой главе, – совместному улучшению, экспериментальному развитию и реализации петли обратной связи. Они помогают понять, что происходит. Во-первых, в буквальном смысле изменилось восприятие процессов не только всеми членами команды, но и руководителем. Визуализация рабочего процесса при помощи канбан-доски выявила раздробленное видение. Менеджеры смогли понять, что работы скапливались, и это убедило их в необходимости введения WIP-лимитов, а также уменьшения управляющих воздействий на команду. Вот пример того, как лимитирование незавершенных работ меняет поведение.
Рассмотрим ситуацию, когда команда постоянно получает запросы от разных менеджеров и ей приходится соблюдать баланс чужих интересов. Каждый руководитель считает свою просьбу самой важной. Если команда работает по запросу одного менеджера, то другой чувствует себя оскорбленным. Все испытывают большое давление, потому что столкнулись с неразрешимой проблемой.
Если эта команда использует Канбан для визуализации рабочего процесса, то все запросы менеджеров по написанию функций будут в итоге находиться в качестве рабочих элементов в первом столбце. Если запросов больше, чем команда способна выполнить, то стикеры накопятся в столбце и каждый сможет это увидеть. Теперь разработчикам понятно, что делать, – нужно получить согласие всех менеджеров на введение WIP-лимита в этом столбце.
Допустим, они договорились и ввели лимит на выполнение незавершенных работ. Менеджеры продолжат добавлять новые функции до тех пор, пока этот WIP-лимит не будет исчерпан. Но как только первый менеджер достигает лимита, он больше не может просто так добавить новый стикер на доску, для этого придется удалить какой-то другой. Если он не хочет удалять один из своих стикеров, нужно будет договариваться с другими менеджерами.
Повторимся: когда менеджер уперся в WIP-лимит, он не обвинил команду. Он признал это как ограничение системы и занялся поиском решения с коллегами-менеджерами. Перед нами важная часть системного мышления. Когда все, кто имеет дело с системой, осознают это, они работают в ее рамках, чтобы решать свои проблемы. И так как все понимают, как работает система, потери и неравномерная нагрузка больше не являются проблемой только одной команды. Это общая проблема, в том числе и для менеджеров.
Так новое поведение проявляется и вне команды. Вместо того чтобы просто обвинять разработчиков за неравномерную нагрузку, в чем необязательно они виноваты, всех начинают волновать стикеры в первом столбце, потому что именно ими будет заниматься команда. Можно организовывать встречи для определения приоритетов, устраивать «торги» между собой или искать любые другие пути, чтобы решить, какие задачи выполнять в первую очередь. Но, главное, команде больше не нужно брать на себя вину, потому что она не должна работать на пределе возможностей.
Другими словами, до внедрения Канбана разработчикам приходилось иметь дело с руководителями, считающими, что команда может выполнить неограниченное количество задач. И они всегда были разочарованы, когда результаты работы не соответствовали обещаниям. С введением WIP-лимита менеджеры с магическим мышлением перестали так думать. Они пересмотрели свое поведение не из желания что-то изменить, а потому что работали в системе, которая побуждала их действовать по-другому. В результате у команды появился временной запас, необходимый для отдыха и качественной работы. Все силы, которые раньше тратились на сепаратные переговоры с менеджерами по удовлетворению их запросов, теперь полностью отдаются работе. Это гораздо более эффективный способ управления командой.
Ключевые моментыОдна из важных целей, которую ставит перед собой канбан-команда, – максимизация потока или скорости, с которой рабочие элементы перемещаются по системе.
Канбан-практика измерения и управления потоком подразумевает измерение потока и корректировку процесса для его максимизации.
Кумулятивная диаграмма потока (CFD) показывает лимит на выполнение незавершенных работ (WIP-лимит), число рабочих элементов, добавляемых ежедневно (скорость поступления), общее количество рабочих элементов в рабочем процессе (список) и среднее время нахождения рабочих элементов в системе (время на выполнение заказа).
Когда скорость поступления и список со временем не меняются, система стабильна, канбан-команды устанавливают WIP-лимит для ее стабилизации.
Когда система стабильна, к ней можно применять закон Литтла, который означает, что среднее время на выполнение заказа всегда равно долгосрочной скорости поступления, поделенной на долгосрочный список.
Если ваша команда может стабилизировать рабочий процесс при помощи WIP-лимитов, то вы сумеете уменьшить время выполнения заказа для пользователей при условии, что они не будут добавлять новые рабочие элементы, сокращающие скорость поступления.
Канбан-команды часто прибегают к процессу явной стратегии, добавляя определение понятия «сделано» или дополнительный критерий внизу каждого столбца на канбан-доске.
Когда канбан-команды постепенно совершенствуют систему, добавляя WIP-лимиты, управляя потоком и используя явную стратегию, они тем самым улучшают управление остальной компанией.
Вы говорите о WIP-лимитах и явной стратегии как об инструментах, способных изменить работу команды. Но этот аргумент кажется надуманным. Или это все-таки правда?
Удивительно, но это правда. Чтобы понять почему, вернемся к истокам Lean и Канбана.
WIP-лимиты – простой, но эффективный инструмент для сглаживания потока, и его эффективность известна уже давно. Канбан базируется на сигнальной системе для создания вытягивающей производственной системы, которая возникла в компании Toyota в 1950-е годы (как и многие идеи и инструменты Lean). Название «канбан» происходит от японского слова, которое означает «сигнальная карточка» (буквально «вывеска» или «рекламный щит»); для обозначения сигнальной карточки принято писать слово «канбан» с маленькой буквы. На станции сборочной линии завода-изготовителя использовалось определенное количество канбан-карточек, на которых печатался номер каждой детали или ее название, требующейся на сборочной линии.
По мере окончания комплектующих на этапе сборочной линии канбан-карточка вставлялась в пустой слот на тележке для деталей; это сигнализировало, что их количество надо увеличить. Так выглядел цикл пополнения сборочной линии, а производственная команда использовала только необходимые в данный момент комплектующие, что позволило всей компании уменьшить общее количество деталей, которые необходимо хранить на складе. Ограничение количества канбан для каждой детали позволило команде установить WIP-лимиты.
Программистам иногда трудно понять, как систему с использованием канбан-карточек можно применить к разработке программного обеспечения. Им не нравится сравнивать себя с персоналом сборочного конвейера – и это справедливо, потому что разработка скорее похожа на то, что делают автомобильные инженеры и конструкторы, а не рабочие. Но в Канбане не принято относиться к людям как к винтикам механизма. Канбан и конвейер объединяет лишь то, что они используют канбан-карточки на контейнерах с запчастями или стикеры на доске, чтобы сигнализировать: еще не все готово.
Иногда легче понять это при помощи примера, не имеющего ничего общего ни с конвейером, ни с программным обеспечением. Каждое лето на большой выставочной площадке в Сент-Поле проводится ярмарка, которую посещает более миллиона жителей штата. На территории выставочного комплекса располагается множество поставщиков продуктов питания. Один из самых популярных – стенд компании – производителя кукурузы гриль. Другие известные поставщики имеют длинные очереди у своих стендов – например, не менее двух десятков людей выстраиваются, чтобы купить жареные оливки на палочке[87]. Но там, где посетителям предлагают кукурузу гриль, как правило, огромное количество людей обслуживается практически без очередей. Как они этого добились?
В отличие от поставщика жареных оливок, который имеет два одинаковых по назначению окна с длинными очередями, на стенде кукурузы гриль созданы два отдельных окна. В первом вы платите деньги и получаете чек, а во втором отдаете чек в обмен на початок кукурузы.
Читать бесплатно другие книги:
