Это знакомо многим командам. Они чувствуют, как медленно вязнут в проблемах, и в конце концов все становится настолько плохо, что некогда думать о работе. В главе 7 рассказывалось, как нарушение рабочей атмосферы, подобно этому примеру, может влиять на код: в итоге разработчики собирают плохо спроектированное программное обеспечение и создают такой исходный код, который имеет технический долг и с которым сложно работать.
Как можно решить эту проблему? Она не всегда становится очевидной даже при ежедневном осмотре канбан-доски, потому что большую часть времени ситуация на ней выглядит вполне приемлемой. На ней бывают дополнительные стикеры, пока команда занимается релизом, но это ожидаемо. В конце концов эти стикеры перемещаются по доске, и кажется, что ситуация вернется в норму. Но команда это нормой не считает (хуже, если она воспринимает это как норму). Могут ли инструменты, о которых мы узнали, помочь выявить и исправить проблемы в команде? Давайте посмотрим.
Дополнительная нагрузка во время работы над каждым релизом приводит к заметному скачку на CFD. Помните, что каждая полоса соответствует одной из колонок на доске, а толщина полосы показывает количество стикеров в соответствующей колонке в этот день. На данной диаграмме одна из полос становится толще после каждого релиза, и со временем это приводит к общему росту диаграммы.
WIP-область диаграммы проясняет причину этой проблемы: работа накапливается в этой колонке, потому что количество работ, поступающих в систему, превышает количество работ, выходящих из нее. Если команда не изменит ситуацию, то с каждым новым релизом эти работы будут проталкиваться назад, а полоса – расширяться после каждого релиза.
Мы видим, что общее количество запросов растет, а это означает нестабильность системы и остановку потока работы через систему. Неудивительно, что команда чувствует, как вязнет.
Команда может не осознавать, что работа «застревает» в одном столбце на канбан-доске. WIP-диаграмма визуализирует это, потому что полоса, соответствующая этому столбцу, со временем утолщается. К счастью, у нас есть инструмент, чтобы сгладить эту неравномерность, – добавление WIP-лимита. Измерение количества «застрявших» элементов работы поможет найти хорошую отправную точку.
Пики еще есть, но
Канбан-команды не просто устанавливают WIP-лимит. Они реализуют петлю обратной связи: поскольку проект продолжается, они постоянно регулируют WIP-лимит на основе новой информации. Если по-прежнему происходит накопление задач, то команда экспериментирует с WIP-лимитом до тех пор, пока не найдет значение, определяющее оптимальный поток. Канбан-команды серьезно относятся к эксперименту: они не просто случайным образом устанавливают эти WIP-лимиты, но проводят эксперименты, создавая гипотезы о том, как WIP-лимиты будут влиять на систему, и тщательно доказывают их, проводя измерения. Это пример того, как команда может улучшить совместную работу и эволюционировать экспериментально.
По мере того как команда совместными усилиями развивает свою систему, она чувствует увеличение потока в повседневной работе. Вспомогательные задачи не вызывают ощущения, будто команда откладывает важную работу по созданию нового функционала, потому что работа по поддержанию так же значима, как и сама разработка функций. Помещая рабочие элементы по сопровождению на доску, команда эффективно продвигает их в число приоритетных работ проекта, может сосредоточить на них свое внимание и лучше выполнять работу (вместо попыток втиснуть эти задачи в свои планы и пытаться спешно их преодолеть, создавая себе лишние трудности).
Существует дополнительное долгосрочное преимущество. Многие проблемы поддержки вызваны технической задолженностью, образовавшейся из-за того, что команда старалась не отставать и была вынуждена накапливать долг. Теперь, когда у нее есть время правильно выполнять работу, она обнаруживает, что будет иметь меньше проблем с поддержкой. Тем временем команда может получать удовлетворение от повышения сосредоточенности на задаче и более стимулирующей рабочей среды, которая позволит ей лучше создавать программное обеспечение.
Нет. Дополнительная работа больше не накапливается, потому что она
Но что если работа по поддержанию занимает все места в очереди? Как тогда будет совершаться разработка?
Если работа по поддержанию превалирует в очереди, значит, руководитель уделяет приоритетное внимание не разработке. Это главный приоритет команды, независимо от того, признает это руководство или нет. Размещение рабочих элементов для поддержки на канбан-доске помогает команде сосредоточиться на заслуживающих внимания первоочередных элементах. Программисты не виноваты, что больше не занимаются новой разработкой. Вероятно, многие из них вовсе не готовы выступать в роли круглосуточной службы поддержки. Но это лучше, чем отвечать за нее и одновременно заниматься разработкой.
Теперь руководство имеет гораздо более точную информацию об успехах команды. Это один из принципов agile-разработки программного обеспечения, описанный в главе 3:
Разработчикам нужен временной резерв, или «пространство для маневра», в расписании. Это дает уверенность, что они успеют хорошо и в срок выполнить работу. В главах, посвященных ХР, мы узнали: при дефиците времени команды «срезают углы» и создают технический долг. Им хочется сделать текущую работу как можно быстрее, потому что впереди всегда больше дел, чем позади.
Атмосфера постоянного отставания оставляет мало места для творчества и душит инновации на каждом шагу. А также убивает качество практик, потому что команды, испытывающие непрерывную гонку, часто не успевают создать ничего, кроме кода. Именно поэтому ХР-команды включают временной запас в свои основные практики.
Команды, использующие Канбан, также ценят временной запас и осознают его влияние на способность каждого своего члена хорошо выполнять свою работу. Поэтому они устанавливают лимит количества текущих работ.
Когда команды вместо следования строгому расписанию используют Канбан для улучшения процесса, они внедряют ритмичную поставку. Для этого они обязуются поставлять программное обеспечение на регулярной основе (например, каждые шесть недель), но не фиксируют определенный список рабочих элементов, которые будут включены в релиз. Вместо этого они доверяют своей системе поставки рабочих элементов. Если они уже избавились от перегрузок и неравномерной работы, то будут получать список незавершенных рабочих элементов в каждой поставке.