Занимательная статистика
По сравнению с некоторыми традиционными гибкими фреймворками управления проектами, Канбан предельно прост для понимания. Эта простота является его основной силой, и поэтому использование Канбан может стать стимулом изменений в способах организации работы.
Рассмотрим, как реализуются практики Канбан в команде разработчиков Канбан в ИТ-проектировании. Практики:
Визуализируйте свой рабочий процесс
В основе Канбан лежит идея о том, что команда должна видеть свой рабочий процесс. Используя визуальное представление рабочего процесса, менеджер проекта может найти потенциал для его улучшения.
Все действия разработчиков планируются, отслеживаются и визуально представляются на доске Канбан. Предоставляются регулярные и постоянные возможности для обсуждения в команде того, как убедиться, что команда сосредоточена и работает над наиболее важными задачами. Ускоренные действия, такие, как исправление ошибок, могут быть визуально представлены другим цветом.
Как вариант, Канбан-доска для ИТ-разработчиков может иметь несколько этапов рабочего процесса:
Журнал невыполненных работ: все функции/действия, которые необходимо выполнить;
Анализ: резерв времени, необходимый для понимания и анализа проблемы, фиксации требований, определения критериев «выход» или «готово» и рассмотрения различных архитектурных подходов;
Дизайн: проектирование первоначального дизайна;
Реализация: внедрение решения;
Проверка: отладка и/или проверка правильности реализации и ее соответствия критериям, определенным на этапе анализа;
Готово: задача / действие соответствует критериям выхода.
Такая доска может содержать отдельный срочный рабочий процесс, создающий емкость для тех неизбежных элементов, которые должны быть ускорены. Конечно, эту «полосу» следует использовать нечасто.
Визуальный аспект Канбан-доски побуждает к обсуждению в команде того, как оптимизировать процессы и методологии команды, чтобы сократить время, потраченное впустую в рабочем процессе команды.
Поскольку визуализация Канбан позволяет всей команде видеть весь процесс в целом, это первый шаг к тому, чтобы позволить команде оптимизировать процесс. Пока команда работает над проектом, всегда есть время внести предложения по добавлению или удалению шагов из процесса — канбан-доска развивается по мере развития процесса. Наличие доски на видном месте создает как механизм, так и возможность обсудить процесс. Обычно это делается во время коротких целенаправленных ежедневных совещаний для обсуждения прогресса и блокирующих проблем (и, в идеале, перемещения задач по рабочему процессу).
Ограничение незавершенной работы
Классический подход к тому, как команда вовлекается в проектные работы, заключается в том, чтобы дать им несколько задач / функций для одновременной реализации, а также обеспечить постоянный поток совещаний для критического осмысления ошибок и определения текущих «быстрых» задач, которые необходимо выполнить в кратчайшие сроки. Очевидно, что это приводит к неэффективности из-за необходимости переключения между задачами. Более эффективным решением является отслеживание того, чтобы каждый человек был сосредоточен на меньшем количестве задач и позволять ему прорабатывать ее до конца. Цель этой практики — ограничить незавершенное производство.
У каждого проекта есть ограничения: люди, вычислительная мощность, лицензии, запланированный отпуск и т. д. Эти ограничения необходимо четко определить и зафиксировать на канбан-доске. Это делается путем назначения лимита незавершенного производства (WIP) для каждого столбца на доске Канбан, отражающего ограничения. Например, предположим, что мы хотим назначить лимит незавершенного производства для фазы реализации. Если у нас есть четыре разработчика и мы делаем предположение, что разработчик может работать не более чем над двумя задачами одновременно, результирующее ограничение WIP равно 8 (= 4 разработчика * 2 задачи на разработчика). Это определяет максимальное количество задач/действий, которые могут произойти на этом этапе процесса.
Ключевым моментом здесь является то, что Канбан использует так называемую систему вытягивания. Если менеджер проекта считает, что лимиты WIP определяют количество свободных слотов, доступных для каждого столбца, то он может переместить задачу в столбец только при наличии свободного слота. Например:
команда не может начать новый элемент из журнала невыполненных работ (бэклога), если фаза анализа достигла пределов незавершенного производства;
однако, как только любой элемент на этапе анализа завершен, он может быть немедленно перемещен на этап проектирования, если там есть один свободный слот;
для столбца «Готово» нет ограничений.
Концепция вытягивания заключается в том, что задачи можно вытягивать только справа, вместо того, чтобы толкать слева. Кроме того, для команды важно определить критерии входа на каждом этапе, чтобы гарантировать, что принятой будет только та работа, которая завершена. Принятие чего-то незавершенного неизбежно обернется затратами времени, а значит, и денег. Возвраты незавершенных задач могут стать бичом любого ИТ-проекта, особенно если их возвращение в поток связано с перенапряжением системы (несоблюдением WIP-ограничений рабочего потока).
Важным моментом, касающимся перехода из бэклога в фазу анализа, является то, что он дает возможность решить, какая задача или функция в данный момент представляет наибольшую ценность. Поскольку на протяжении проекта из-за появления новой информации или технических проблем приоритеты часто меняются, возможность пересмотреть решение о том, что следует реализовать быстрее или как можно позже, является ключевой ценностью использования такой непрерывной системы, как Канбан.
Как только ограничения WIP установлены, становится очевидным, где существуют узкие места в процессе, потому что тот или иной конкретный элемент создает обратное давление для предшествующих действий. Увеличение лимитов незавершенного производства, скорее всего, будет означать, что задачи задерживаются в столбце слишком долго и работа слишком сильно затягивается.
После того, как начальный набор лимитов WIP определен, их, вероятно, потребуется настроить по мере продвижения проекта. Это естественно и этого следует ожидать. Один из подходов заключается в том, чтобы наблюдать за тем, насколько плавно задачи проходят через канбан-доску, и экспериментальным путем находить оптимальный вариант WIP, увеличивая и сокращая пределы незавершенного производства, чтобы сгладить этот поток.
Управление потоком
Одной из важных организационных целей любого проекта является налаживание максимально эффективного использования ресурсов команды для решения задач проекта. Визуальный аспект и лимиты незавершенного производства, рассмотренные в предыдущих разделах, помогают определить узкие места и помочь команде оптимизировать поток действий от начала до конца.
Обеспечение прозрачности политик
Как говорится, «лучшим дезинфицирующим средством является солнечный свет». Это означает, что только когда политики явны, можно увидеть проблему.
Цель этой основной практики — четко сформулировать любые базовые политики в рабочем процессе, т. е. то, как все делается на самом деле. После того, как они сформулированы, они становятся «фактами» для проекта и, следовательно, уменьшают любой субъективный анализ или эмоциональную нагрузку, связанные с процессом разработки.
Важно создавать возможности для обзора процесса с помощью собранных объективных доказательств или отдельных фактов. Эти возможности можно использовать для создания идей по улучшению, с которыми все согласятся, потому что обсуждение основано на реальных фактах. В идеале, эта обратная связь должна осуществляться всякий раз, как будет накоплено достаточно доказательств существования проблемы. Проблема должна быть подвергнута содержательному обсуждению, которое иногда может продолжаться неделями или месяцами.
Возникновение узких мест - это также возможность обсудить идеи. Идеи после обсуждения могут быть помещены в список невыполненных работ (или задач) для определения приоритетов и добавления, когда освободится следующий доступный слот.
Ежедневные совещания дают возможность объективно обсуждать вопросы.
Канбан-доска, будучи физическим элементом, позволяет людям говорить о «доске», а не о «человеке». Перенося обсуждение в поле «задачи» («Что мешает продвижению задачи А?»), менеджер может устранить такую распространенную проблему, как «переход на личности» («Почему вы так долго решаете задачу А?»).
Совместное совершенствование, экспериментальное развитие
В контексте реализации ИТ-проектов, Канбан предоставляет ключевые метрики (например, кумулятивные блок-схемы CFD), которые могут дать реалистичное представление о:
текущем состоянии ИТ-проекта;
некоторое представление о прогнозируемом графике на будущее;
некоторые ключевые данные, необходимые для перспективного планирования.
Вся эта информация увязывается с существующими структурами управленческой отчетности и может обеспечить даже более реалистичное представление о реальном статусе проекта, нежели, скажем, диаграмма Ганта.
Поскольку Канбан — это непрерывный поток, есть возможность и даже необходимость обсудить изменение элемента рабочего процесса в любой момент. Как правило, это связано с хроническим состоянием фазы процесса, которая становится тем самым «узким местом». Это требует от команды нахождения решения задачи по устранению узкого места или улучшению потока. В идеале, такое решение находится на основании надежных эмпирических данных, показывающих постоянное возникновение узких мест в указанной фазе.
После того, как будет принято решение о варианте улучшения, его следует запланировать, как и любую другую задачу, добавив ее в начальную фазу; в нашем случае это журнал невыполненных работ (бэклог), а затем внедрив его. Поскольку собор метрик продолжается, команда сможет объективно определить, улучшила ли идея производительность команды, или, напротив, ухудшила.
Теория, лежащая в основе этой основной практики Канбан, заключается в том, что проблемы определяются с точки зрения долгосрочной перспективы, вносятся изменения на основе фактов, а затем проводится фиксация результатов для обнаружения проблем. Таким образом, совершенствование носит циклический, непрерывный характер, а оптимизация методов ИТ-проектирования с помощью Канбана упрощается.
