День 261. Канбан (II)

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

СНИЖЕНИЕ КОЛИЧЕСТВА НЕЗАВЕРШЕННЫХ ЗАДАЧ И ЧАСТЫЕ РЕЛИЗЫ

1. burndown диаграмма

Много информации о ходе выполнения проекта (развития продукта) можно извлечь из burndown диаграммы, которая показывает динамику количества оставшихся задач.

Иногда ее рисуют перевернутой и анализируют размер бэклога (в таком случае ее еще называют кумулятивной диаграммой потока):

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

По такому графику можно отследить две важные метрики:

Первая метрика — количество задач в бэклоге (незавершенные задачи — разница между общим количеством бэклога и завершенными задачами) обозначено WIP (Work in progress) 

Вторая метрика — среднее время ожидания реализации задачи (по каждой задаче смотрим, сколько времени прошло с момента ее описания до релиза)

Важнейшая задача Канбана — такая организация разработки, при которой среднее время реализации задачи будет сокращено насколько это возможно, а размер бэклога не будет расти

Впрочем, уменьшаться он тоже не должен (в таком случае это бы означало, что продукт не развивается, то есть бизнес не ставит перед разработкой амбиционзые задачи)

2. Эмпирический закон: чем короче итерации, тем выше качество

Практика показывает, что короткие итерации ведут к сокращению количества задач в очереди и времени ожидания.

Впрочем, необходимо находить компромисс между расходами на разработку и накладными (операционными) расходами на подготовку релиза, прогон тестов и сам релиз. Грубо говоря, если за день разработка выпускает 10 у.е. бизнес-ценности, а подготовка релиза отнимает время, соответствующее 3 у.е — возможно, ежедневный выпуск релиза не имеет смысла (30% будут составлять накладные расходы)

Крайним случаем коротких итераций является так называемая continuos deployment

3. Частые релизы ведут к доверию со стороны заказчика

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

Как у нас в piano: до continuous deployment мы еще не дошли, но релизы выпускаем каждый день.

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

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

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

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

ТРИАЖ ИЛИ ГРУММИНГ

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

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

Цель проведения триажа бэклога — сокращение его размеров. Преимущество меньшего размера бэклога — в облегчении процедуры обсуждения приоритетов. Выбирать из 200 элементов гораздо проще, чем из 2000.

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

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

Сахаров Денис
Сахаров Денис
Был на сайте сегодня в 15:47
Читателей: 21 Опыт: 920.487 Карма: 10.1215
все 22 Мои друзья