Канбан в ИТ-проектировании. Метрики и их использование для оптимизации процесса разработки
Занимательная статистика
Канбан предоставляет две ключевые метрики для объективного измерения производительности команды: время выполнения заказа и время цикла.
Время выполнения — это время от момента, когда задача входит в фазу запуска, до момента, когда она выходит из фазы завершения, т. е., в нашем примере, это дельта времени с момента, когда задача вводится в столбец «Незавершенная работа», до момента, когда она перемещается в столбец «Готово».
Время выполнения также должно управляться, чтобы обеспечить своевременную доставку функций. Команда может оптимизировать время выполнения заказа одним из следующих способов:
разбиение шага на несколько более мелких шагов;
объединение нескольких более мелких шагов в один;
автоматизация через скрипты;
добавление дополнительных ресурсов, например, вычислительной инфраструктуры;
дополнительные циклы тестирования/обзора для ограничения деятельности по отходам на последующих этапах.
Основная проблема при разработке программного продукта заключается в том, что одна и та же функция может быть более сложной в одной области, чем в другой. Например, конкретную функцию может быть сложнее реализовать, чем проверить, и наоборот. Временем выполнения таких функций можно управлять, разбивая задачу на применимые домены. При этом необходимо включить конечную задачу интеграции, чтобы гарантировать, что когда функция выполнена, она включает интеграцию отдельных доменов в полную функцию.
Еще одна метрика — время цикла, которое измеряет, когда работа над задачей фактически началась и когда она была завершена. Это не измерение усилий, а продолжительность пребывания цикла в системе. Время цикла — это время, необходимое для того, чтобы функция перемещалась от начала до конца вашего процесса, а время выполнения — это время между тем, когда функция входит в ваш процесс и выходит из него. Расчет среднего времени выполнения заказа и времени цикла дает представление о вашем рабочем процессе. Сравнение средних показателей времени выполнения задачи на различных этапах может предоставить эмпирическое доказательство того, что процесс улучшается.
После того, как собран надежный набор эмпирических данных о времени выполнения заказа и времени цикла, для расчета пропускной способности команды следует использовать закон Литтла: долгосрочное среднее количество заявок в устойчивой системе (L) равно долгосрочной средней эффективной частоте прибытия (λ), умноженной на среднее время, которое клиент проводит в системе (W).
Выразим эту идею алгебраически:
L = λW
Или в терминах Канбан:
Среднее время цикла = Среднее время работы над задачей / Средняя пропускная способность
Когда процесс проходит этап настройки, пропускная способность должна показывать, улучшило ли изменение рабочий процесс или нет.
Используя описанные основные практики и метрики, команда может визуально увидеть следующие проблемы в своем рабочем процессе:
выявить узкие места;
выявить области «торможения» рабочего процесса;
выявить области улучшения потока.
Правило управления потоком основано на учете того обстоятельства, что весь процесс должен постоянно пересматриваться ради нахождения способов сделать вашу команду более эффективной и продуктивной. Другими словами, ключ в том, чтобы найти и устранить расточительные действия в вашем процессе.
Для команд разработчиков рекомендуется, чтобы перед тем, как процесс Канбан в проекте будет запущен, четкое представление о общей картине проекта имели все его участники. Область знаний о проекте должна включать набор приоритетных функций, которые будут реализованы, и первоначальный архитектурный взгляд на то, как все функции будут работать вместе. Чтобы было ясно, это архитектурное представление должно охватывать все части системы, включая, помимо прочего, проектирование, тестирование, физическое проектирование и программное обеспечение, если это необходимо. Получив это представление, по мере развития проекта команда может затем предоставить рекомендации о том, как следует разрабатывать взаимозависимые функции. Это снижает вероятность переделок из-за неправильной сборки.
ИТ-проектирование и Канбан. Акцент на устранении потерь
Ключевым элементом Канбан и бережливого производства является акцент на устранении потерь. В среде проектирования потери вызваны, как правило, расточительными действиями, такими, как:
1) выполнение большего, чем нужно
Позиция «эта функция когда-нибудь пригодится, давайте добавим ее» недопустима в ИТ-проекте. Команда должна сосредоточиться только на том, что необходимо сейчас, то есть на выполнении задачи наиболее оптимальным образом. Это не означает, что нужно исключить очень ценную задачу разработки модуля/класса для размещения будущих функций, но во главе угла должно стоять понимание того, что следует рассматривать только ту работу, которая добавляет ценность.
2) Выполнение того, что нужно, неоптимальным способом
Следует создавать только то, что абсолютно необходимо для завершения работы. Выполнение работы, которая не способствует решению поставленной задачи, является пустой тратой усилий, тем более, что крупные проекты в области ИТ-разработки — это дорогостоящие наукоемкие проекты. Поэтому любая лишняя или бесполезная работа должна быть исключена и это должна осознавать вся команда.
3) многозадачность
Многозадачность всегда повышает издержки, поскольку стоимость переключения контекста может быть высокой. Ограничения WIP определяют границы «растяжения» усилий команды.
4) незавершенность / неполнота исполнения
Канбан способствует идее четкого определения момента выполнения задачи с помощью критериев входа и выхода из каждого столбца.
5) ожидание / простой
Отговорка «Я не могу начать это задание, пока не получу его от…» в системе Канбан не работает. Визуальная доска и ежедневные встречи создают возможность обозначить блокирующие задачи. Типичным примером в ИТ-проекте является ситуация, когда проект ожидает среды проверки. Канбан может помочь в этом, разделяя задачи проверки на создание простой среды проверки работоспособности системы, а затем добавляя задачи, усложняющие среду проверки.
6) ошибки выбора ресурса / задачи
Отговорка «Попросите Вову сделать это, пока он не занят» в системе Канбан не работает.
Назначение кого-то, кто доступен, но недостаточно компетентен, обычно заканчивается работой низкого качества, которая занимает больше времени, чем хотелось бы, и неизбежно требует переделки позже. Любая переделка - пустая трата времени. Хотя Канбан не предоставляет никакого механизма для выделения этой проблемы, он помогает выявить ее именно как проблему, требующую решения, поскольку задача, поддерживаемая ошибочно назначаемыми ресурсами, вероятно, займет больше времени, чем обычно.
Интеграция методологии Канбан
Ниже Вы найдете рекомендации относительно того, как команда разработчиков может интегрировать подход Канбан в свой текущий рабочий процесс. Эти рекомендации частично основаны на практическом опыте и лучших практиках сообщества разработчиков программного обеспечения.
Канбан по сравнению с другими Agile-методами представляет собой очень простую методологию с очень низкими накладными расходами и простыми правилами, которые можно легко принять. Тот факт, что он не прерывает шаги, которые находятся в процессе, является его сильно стороной, потому что его можно и даже необходимо интегрировать в уже существующий рабочий процесс, вследствие чего команда сможет самоорганизоваться и, при необходимости, продолжить улучшение рабочего потока.
Итак, что же можно сделать для постепенного внедрения Канбан в ваш поток? Есть три японских термина для описания перехода Канбан-команд от позиции новичка к статусу мастера:
SHU – место, где изучаем основы техники или методологии;
Ha - понимание основ и постепенного внедрения и адаптации нового метода;
RI - овладение техникой, использование расширенных данных и внедрение новшеств.
Рассмотрим эти стадии подробно.
I. SHU - Знакомство с канбан
Предлагаем этапы внедрения Канбан в команду:
Фаза 1 — обучение: привлеките специалиста, чтобы узнать о Канбан больше.
Фаза 2 – визуализация потока: осуществите записи текущего процесса с помощью доски. Начните с того места, где сейчас находится команда. Визуализация – это не образ того, как вы хотите работать, а фиксация того, как работа осуществляется на самом деле. Хорошая, то есть информативная и точная визуализация – это отличный старт для тех, кто внедряет Канбан. Далее следует убедиться, что команда понимает критерии входа и выхода для каждого этапа.
Фаза 3 - добавление лимитов WIP. Добавление лимитов WIP должно быть основано на реальности. Хороший вариант — начать с расчета WIP как произведения количества инженеров / специалистов на разумное среднее количество единовременно выполняемых каждым из них задач. Специалисты Канбан рекомендуют начинать с малого и постепенно увеличивать показатель WIP опытным путем, например, когда свободные слоты остаются открытыми слишком долго или время цикла слишком велико. Это начинает определять узкие места и ограничения ресурсов.
Фаза 4 – обзор. Обзор можно осуществлять на всех этапах. Целью является обсуждение хода процесса и устранение узких мест, а также улучшение того, что (и как) делается.
II. НА — использование Канбан
Как только базовые навыки Канбан сформированы, можно приступить к внедрению методологии.
Фаза 1 — сбор показателей. Начните сбор доступных показателей. Это предоставит объективные данные, на основе которых могут быть осуществлены прагматические изменения. Кроме того, сбор данных обеспечивает основу для объективного определения того, действительно ли какое-либо изменение процесса повысило производительность команды.
Фаза 2 — использование метрик. Метрики, собранные во время любых обсуждений, используются для улучшения оценки задач / мероприятий и для разумного планирования объема работ, с которым команда может справиться.
III. RI - Освоение Канбан
На данном этапе команда полностью разбирается в использовании Канбан. Используя собранные данные, вы теперь можете включить их в свои будущие сеансы планирования, чтобы оценить продолжительность набора задач, стоящих перед вами. Теперь ваше планирование основано на эмпирических данных, а не на иллюзорных предположениях. Поскольку оценки основаны на эмпирических данных, Вы можете быть уверены в их точности.
В заключение отметим, что любые изменения сложны, разрушительны и могут быть неудобными для многих людей в команде. Настоятельно рекомендуется адаптировать Канбан (или любой новый процесс) поэтапно, не забывая о значительных проблемах людей, которых введение новой техники касается непосредственно.
Ничто так не пугает людей, как неизвестность. Если изменение и его цели не будут поняты полностью, в большинстве случаев люди негативно отреагируют на изменения. Шансы на успех возрастут, если обучение и внедрение Канбан будет произведено постепенно.
Наконец, следует иметь ввиду, что представленное обсуждение Канбан предназначено только для старта. Хотя Канбан сам по себе относительно прост, мотивы его использования и контекст, в котором он был разработан, могут потребовать дополнительных разъяснений. Чтобы узнать больше о Канбан и о том, как этот метод применяется в бережливом производстве и разработке продуктов, имеет смысл обратиться к специальной литературе. Таким образом, использование Канбана для повышения эффективности ИТ-проектирования трудно переоценить.
