August 24th, 2010

Cartmendum

Визуализация времени жизни задачи

В широких кругах принято считать, что канбан включает в себя лишь три практики:
  • Pull-подход - задачи в работу не впихиваются насильно, а берутся самостоятельно именно в тот момент, когда есть возможность взять задачу в работу, а не когда пришла очередная заявка
  • Limit Work To Capacity - число задач в работе жестко лимитировано сверху (про это буду писать отдельно, когда соберусь описать как из Burn-Down chart-а получился Inventory)
  • Measure Cycle Time - измеряется и минимизируется время всего цикла. Оптимизация нацелена именно на сокращение этого времени, а не на оптимизацию каких-либо отдельных фаз
Так вот, теперь доска (в реинкарнации 331) научилась визуализировать время жизни каждой завершенной задачи и можно считать что она полностью Kanban-compliant.

Вот пример одной такой картинки, взятой с доски:
Sample 01

С момента создания до момента закрытия задача проходит ряд состояний. Время жизни задачи в состояниях относящимся к потерям красится красным, время жизни в NVAT (Non Value Added Time) состояниях - желтым, время в VAT (Value Added Time) - зеленым.

Про смысл VAT/NVAT/Waste времен писал тут, но так как это было закопано глубоко, думаю, есть смысл повториться.

В оригинале Lean выделяет два типа времен:
  • VAT (Value Added Time) - время в течении которого реально создается ценность для конечного пользователя
  • Waste - время, в течении которого ценность не создается. Например, ожидание разработки или ожидание тестирования.
Но для новичков вводят еще одно понятие (точно не помню откуда я это взял, но похоже из MIT-овских лекций Introduction to Lean Six Sigma Methods):
  •  NVAT (Non-Value Added Time) - в это время тоже не производится ценности для конечного пользователя, но в отличии от Waste NVAT время имеет другое происхождение - это время, которое приходится тратить для соблюдения текущих процессов. Например время приемки задачи заказчиком.
Горизонтальная ось размечена в астрономических (не рабочих) часах и этому есть своя причина. Во-первых мы стремимся уменьшить именно астрономическое время от получения задачи до ее закрытия (у меня даже возникают мысли об организации Follow The Sun поддержки), во вторых, в типичных задачах зеленого на столько мало по сравнению с красным, что выкидывать из зеленого еще и не рабочее время, просто нецелесообразно. Когда 80% задач будут иметь VAT больше 30-40%, тогда нужно будет задумываться о более глубоком анализе, а пока этой оценки сверху вполне достаточно.

Вот еще примеры полосочек:
Sample 02
Это типичная бага, при чем по мнению "заказчика" критичная - она совсем не много ждала в очереди, потом ее достаточно быстро исправили, после чего быстренько оттестили и потом двое суток ждали подтверждения, что теперь все стало хорошо.

Или вот запрос на небольшую доработку:
Sample 03

Днем получили задачку, к вечеру начали ковырять, на следующий день доделали и она пошла ждать в очереди тестировщика. Потом ее долго тестили (тестирование я отнес к NVAT, хотя Lean считает выявление дефектов чистой потерей), потом еще немного подождала, ее за денек приняли и не спеша зарелизили.

А вот это пример настоящего Emergency Release:
Sample 04

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

А вы как думаете, на сколько эффективно у вас используется время жизни задач?
В этом блоге можно найти еще что-нибудь интересное
</div>