Занимательная статистика
В начале XXI века Канбан вышел из сферы автомобильной промышленности и был успешно применен в других сложных коммерческих секторах, таких как телекоммуникация, разработка программного обеспечения, исследования и разработки и т.д. По мере роста интереса к вопросам обеспечения эффективности и использование достижений в области компьютерных технологий, ключевые игроки индустрии программного обеспечения быстро поняли, как Канбан может положительно изменить способ производства продуктов и услуг.
За последние 13-15 лет определение Канбан претерпело собственную эволюцию в ИТ-секторе. Здесь Канбан считается методом, который обеспечивает гибкость в управлении и улучшении предоставления услуг постепенным, эволюционным образом.
То, что разработчики программного обеспечения называют «методом Канбан», стало результатом многолетнего тестирования, обобщения опыта и совместных усилий ведущих специалистов делового и академического сообщества по вопросам Lean и Agile. Среди них можно назвать Дэвида Андерсона, Дэна Ваканти, Даррена Дэвиса, Кори Ладас, Доминика ДеГрандис, Рика Гарбер и других. Растущее сообщество Kanban признало их идеи и вклад в развитие методологии.
Канбан-метод предоставляет важные принципы и методы для лучшего управления обязательствами по соглашению об уровне обслуживания (SLA), своевременной доставки продуктов на рынок и минимизации рисков и затрат, связанных с задержкой. Используя такие концепции, как «класс услуг», «отложенное обязательство» и «двухэтапное принятие», Канбан помогает клиентам и группам доставки эффективно сотрудничать и гарантирует, что нужные работы выполняются в нужное время.
Команды разработчиков прикладного программного обеспечения и технических продуктов приняли Канбан как способ реализации принципов Lean и Agile. Канбан-метод предоставляет технологическим командам отличный набор принципов для визуализации их работы, непрерывного предоставления продуктов и услуг и более частого и быстрого получения обратной связи от клиентов. Следовательно, это помогает командам быстрее выходить на рынок с большей готовностью к тому, чего хотят клиенты.
В целом, Канбан реализует все принципы Agile Manifesto и помогает предоставлять продукты и услуги, которые действительно нужны рынку. Появление в последние годы методов Upstream Kanban, Portfolio Kanban и Enterprise Services Planning дало предприятиям еще больше оснований для внедрения Канбан для достижения гибкости предприятия и повышения эффективности на рынке.
Давно замечено, что в среде разработчиков программного обеспечения Канбан-команды более продуктивны, потому что они сосредоточены только на работе, которая активно выполняется. Но это не единственное ключевое преимущество Канбан для разработчиков. Остановимся на других преимуществах более подробно.
Время цикла — это количество времени, которое требуется одной единице работы, чтобы пройти через весь рабочий процесс команды от начала до конца. Когда только один или два человека обладают набором навыков, необходимым для выполнения определенных задач, время цикла часто увеличивается. Пробуксовки в работе начинают образовывать «узкое место» в рабочем процессе, и система дает сбой.
В Канбан-командах участники имеют общие навыки, а это означает, что пробуксовки не будет. Разработчики могут вмешиваться, когда это необходимо. Вся команда несет ответственность за перемещение элементов по рабочему процессу. Перекрывающиеся наборы навыков означают, что участники команды разработчиков могут выполнять работу в более сжатые сроки, что является ключевым преимуществом команд Канбан.
Важным показателем Канбан является «незавершенное производство» или WIP. Команды ИТ-разработчиков успешно используют те же самые принципы Канбан, чтобы привести объем незавершенной работы (WIP) в соответствие с возможностями команды.
Команды устанавливают ограничения на количество элементов на любом этапе, чтобы предотвратить возникновение узких мест. Если определенный этап достигает своего предела, члены команды перенаправляют свои усилия и сосредотачиваются на этом этапе, чтобы помочь расчистить путь и быстрее перемещать элементы по рабочему процессу. Таким образом, устранение проблем и задержек является частью самой системы. Отслеживание этого процесса помогает командам совершенствоваться по мере их продвижения и более уверенно прогнозировать результаты выполнения задач в будущем.
Например, если команда решает назначить конкретного владельца продукта, она будет нести ответственность за возможное отставание. Члены канбан-команды могут делать это свободно, так как занимаются только незавершенными элементами. Изменения в бэклоге не прерывают и не отвлекают остальную часть команды.
Еще одно преимущество, о котором стоит упомянуть, — это непрерывный логистический и информационный потоки. Некоторые команды ИТ-разработчиков выпускают работу ежедневно или даже ежечасно. Чем быстрее команда внедряет инновации, тем более конкурентоспособен их продукт на рынке ИТ-разработок.
Таким образом, команды, которые практикуют Канбан, обычно самоуправляемы — они самостоятельно определяют, когда и как будет завершена работа. Ресурсы извлекаются только по мере необходимости или запроса, а товарищи по команде заявляют о работе на основе фактической пропускной способности. Это огромный контраст с назначением будущей работы кем-то другим, использующим оценки мощности.
Таким образом, метод Канбан обеспечивает командам разработчиков высокий уровень прозрачности их работы. Он также позволяет сосредоточиться на нескольких важнейших задачах текущего момента и включает в себя механизмы выявления и решения проблем, заложенный в самом цикле. Такие преимущества методологии Канбан в сфере ИТ-разработок трудно оспорить, особенно, если инструменты, необходимые для его поддержки, уже есть.
Канбан в ИТ-проектировании. Причины внедрения
На фоне возрастающей сложности тестируемых программных продуктов, тестирование становится важнейшей задачей для многих проектов в ИТ-сфере. Улучшенные инструменты и стандартизированные методологии играют большую роль этом процессе, бизнес-аналитикам и руководителям ИТ-проектов имеет смысл изучить альтернативные способы организации команды разработчиков. В частности, многие команды разработчиков программного обеспечения уже много лет успешно применяют agile-методы, такие как Extreme Programming (XP), Evolutionary Prototyping, Scrum и другие. Эти методологии были успешно адаптированы для решения задач проектов разработки программного обеспечения. «Канбан» - более поздняя методология, но она также предлагает некоторые интересные возможности, которые могут дополнить существующий процесс управления командой ИТ-разработчиков.
Вот основные причины, по которым следует рассмотреть возможность использования Канбан-подхода при разработке ИС:
Канбан обеспечивает визуальное представление процесса разработки, позволяя команде легко определить, где есть возможности для оптимизации рабочего процесса (т.е., в терминологии бережливого производства, устранить потери);
Канбан выделяет проблемы и узкие места в процессе, чтобы команда могла использовать нужные ресурсы для скорейшего решения любых проблем;
Канбан создает возможности для обсуждения, чтобы гарантировать, что команда всегда работает над функцией, которая имеет наибольшую ценность для клиентов;
Канбан обеспечивает более реалистичное представление об истинном текущем состоянии проекта, а также представление о запланированном завершении благодаря улучшенным объективным показателям проекта.
Самое главное, его легко внедрить, поскольку можно начать с простого захвата существующего процесса, а затем постепенно оптимизировать процессы своей команды или проекта. Другими словами, не нужно менять способ управления вашей командой, вместо этого можно поэтапно внедрять Канбан в рабочий процесс.
Если необходимо точно знать, в каком текущем состоянии находится проект, выявлять узкие места и быстро выявлять риски, проявляющиеся во время разработки, в доступной для понимания форме, есть смысл использовать Канбан.
Существует множество инструментов, которые помогают командам следовать подходу Канбан, но ключевым преимуществом Канбан является именно то, что он не требует ничего более сложного, чем доска и стикеры.
Сегодня существует много веб-решений для внедрения практик Канбан, но не стоит торопиться с их использованием до того, как это изменение будет презентовано команде. Команда должна быть знакома с методами и основными принципами Канбан, а для этого на первом этапе проще использовать простую физическую доску и стикеры, и лишь потом стоит внедрять автоматизированные методы управления рабочим потоком.
Повседневные проблемы, с которыми сталкиваются разработчики в процессе создания своих продуктов и проверке сложных систем, - это:
возрастающая сложность разработки программных продуктов;
увеличение размера команды проекта, что, в свою очередь, увеличивает сложность внутренних коммуникаций;
неизбежное использование распределенных команд, что увеличивает сложность как командной динамики, так и внутренних коммуникаций;
постоянная необходимость в информации о текущем состоянии проекта и связанный с этим дефицит информации и несовершенство методов для ее получения;
ограниченные возможности для изучения новых методов и методологий, находящихся в стадии разработки.
Каждый проект испытывает на себе сильное влияние по крайней мере один из этих факторов. В ситуации работы с удаленными командами разработчиков зачастую просто невозможно составить реалистичный график, удобный для всех, поскольку по самой своей природе создаваемые программные продукты имеют слишком много неизвестных и рисков; это:
технические риски – обычно осуществляется разработка того, что еще никогда не создавалось, поэтому у разработчиков нет предыдущего опыта для детерминистической оценки сложности проекта или элемента;
технологические риски – часто разработчики вынуждены использовать новый инструмент, методологию или технологический процесс. В большинстве случаев задача быть на переднем крае технологий означает, что им придется иметь дело с непредвиденными ошибками;
человеческие риски – команда, которая запускает проект, - это, как правило, не та команда, которая его завершает. Часто члены команд переключаются между проектами, и им бывает необходимо поддержать прошлую работу или посмотреть на будущие возможности;
ресурсный риск — во многих крупных компаниях любые физические ресурсы, такие как вычислительные фермы, лицензии и т. д., используются несколькими проектами совместно. На каком-то этапе проекта конкуренция за ресурсы неизбежна, что, вероятно, приведет к незапланированным задержкам.
Метод Канбан — это не панацея, которая решает все эти проблемы. Но он может помочь команде работать целенаправленно и дисциплинированно, понять их следующую наиболее важную задачу и четко определиться с тем, что осталось сделать.
Подводя итог, можно сказать, что Канбан — это простой инструмент управления процессами, который может предоставить командам ИТ-разработчиков дополнительную гибкость и мощность для управления рабочим процессом. В этом и заключается основная причина того, почему Канбан в сфере ИТ-технологий получает все большее признание и применение.
