День 270. Канбан (V)

Закончим выдержки из книги Дэвида Андерсена «Канбан»:

АНАЛИЗ КУМУЛЯТИВНОЙ ДИАГРАММЫ

Основная идея, лежащая в основе данного анализа (которую я, кстати успешно внедрил на прошлом месте работы и пока безуспешно продвигаю в Piano) состоит в том, что для получения содержательных данных недостаточно одной метрики. Взятие среднего, например, сглаживает картину и убирает выбросы.

В качестве простого примера рассмотрим одну из метрик, используемых в БАРСе — обработка поступающих запросов.

У нас был проект по технической поддержке большого количества пользователей (достаточно типичная ситуация) и совместно с заказчиком мы решили разработать какие-то показатели, позволяющие оценить оперативность нашей работы.

Таким показателем было время решение заявки.

Очевидно, что если взять только одну метрику (например, среднее) для этого показателя — информация будет неполной. Например, большинство заявок решается очень быстро и среднее время хорошее и соответствует принятым соглашениям по качеству обслуживания, однако есть некоторые выбросы по отдельным заявкам, которые приводят к негативу конечных пользователей.

Самый простой выход — взять две метрики: среднее время и максимальное. Тогда мы сможем контролировать и поток, и выбросы.

Типичными показателями для Канбана являются следующие: 

1. пропускная способность (аналог сторипойнтов, выполненных за спринт)

Данные о пропускной способности используются в Канбане с совершенно иными целями, чем скорость в типичной среде гибкой разработки. Пропускная способность не применяется для предсказания количества выполненных элементов за период или для принятия обязательств по объемам производства. Это лишь индикатор того, насколько хорошо действует система (команда и организация) и идет ли постоянное развитие. Обязательства в Канбане принимаются по времени выполнения и целевым датам выполнения.

2. Проблемы и блокированные элементы (те, что выбиваются из общей картины, которые долго висят на доске)

ОРГАНИЗАЦИОННЫЕ СБОРЫ

В Канбане нет ежедневных синкапов и ретро с планированиями как в SCRUM. Однако проведение совещаний необходимо. Их частота может варьироваться (в среднем раз в месяц)

1. Участвуют все сотрудники и менеджмент. Именно такая практика у нас была в БАРСе — когда каждый департамент рассказывал о своей работе за прошедший месяц

2. Такие совещания ведут к доверию между сотрудниками и руководством

3. Освещаются не только успехи, но и проблемные места

4. Проблемы фиксируются и по этим пунктам ведется работа — менеджеры ведут систематическую работу по проблемам и предложениям.

Эту практику я позаимствовал из БАРСа и недавно мы начали ее использовать и в Piano — ведем гуглдок с отмеченными проблемами в командах, в компании вцелом, в коммуникациях с американским офисом — и каждый менеджер отслеживает прогресс.

ПРОЕКТНОЕ УПРАВЛЕНИЕ В КАНБАНЕ

В традиционном управлении проектами обязательства принимаются на основании трех сдерживающих факторов: объема, расписания и бюджета. После определенного этапа оценки и планирования выделяется бюджет на привлечение ресурсов, затем определяется объем требований и расписание.

Agile-управление проектами, однако, не дает таких смелых и четких обещаний. Дата окончания работы — примерно через несколько месяцев — может быть определена, но общий объем никогда не устанавливается. Он может определяться приблизительно, но детали никогда не фиксируются.

Нередко заранее оговаривают бюджет (среднемесячные зарплаты), чтобы привлечь к работе фиксированные ресурсы. Agile-команда действует итеративно, предоставляя обновления функциональности за время коротких, ограниченных по времени итераций (или спринтов). Обычно они занимают от одной до четырех недель. В начале каждой из этих итераций проводят оценку и планирование, после чего берут обязательства. Часто обозначают и объем, но если команда не может выполнить обязательство в срок, то жертвуют именно объемом, а дата окончания остается неизменной. На итерационном уровне гибкая разработка похожа на традиционное управление проектами. Ключевая разница состоит в договоренности о том, что в случае форс-мажорных обстоятельств объем будет сокращен. Менеджер проекта традиционного типа имеет в этом случае возможность выбрать, чем пожертвовать — объемом или расписанием, добавить ресурсы или принять смешанное решение.

Канбан предполагает иной тип сделки. Он вообще не берет обязательств, основанных на чем-то неопределенном. Типичный вариант Канбана предполагает соглашение о регулярных релизах высококачественного работающего ПО — например, каждые две недели. Внешним заинтересованным лицам предлагается полная прозрачность рабочего процесса и, при желании, визуализация ежедневного прогресса. Кроме того, они получают возможность выбирать самые важные новые элементы для разработки.

Канбан не обещает выполнить определенный объем работы к назначенному дню. Он дает обязательства в соответствии с соглашениями об уровне обслуживания для каждого класса обслуживания в сочетании с обязательствами по выпуску надежных регулярных релизов, прозрачности, гибкости работы и расстановки приоритетов, а также по непрерывному совершенствованию качества, пропускной способности, частоты релизов и времени выполнения.

ДАЛЬНЕЙШЕЕ РАЗВИТИЕ

Описанные выше основы Канбан легко дополняются следующими методологиями (они выходят за рамки данной книги): 

1. Теория ограничений

Анализ потока создания ценности с целью выявления узких мест с дальнейшим расширением, либо оптимизацией. Основное правило — нет смысла оптимизировать другие места, кроме бутылочного горлышка.

2. Бережливое управление

Выявление и оптимизация дополнительных расходов:

— накладные расходы (которые не несут бизнес-ценности, но требуются для выполнения работ по ее созданию): расходы на координацию, расходы на планирование, на расстановку приоритетов, на подготовку и выпуск релиза

— ошибочная нагрузка (работы, которых можно избежать, если предыдущий релиз был высокого качества): звонки в службу поддержки, исправление дефектов промышленной среды

3. Система Деминга 

Понимание вариативности и ее влияния на производительность, а также понимание, находятся ли отклонения в пределах статистической погрешности или обусловлены особыми причинами. 

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте сегодня в 12:53
Читателей: 19 Опыт: 836.267 Карма: 10.1215
все 20 Мои друзья