"зависания" в канбане

[Pavel Aksonov]

Всем привет,

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

Но есть одна проблема. Вопрос с "зависаниями" (когда ОДИН из команды работает над чем-то долго, зацикливается) - тут все продолжает крутиться,
так как один "зависший" тикет мало влияет на WIP  и т.д.
Но страдает эффективность. Тут вспоминаются слова Коли про то, что канбан хорош для высокоорганизованных команд. В таком
случае команда сама поможет "зависшему" и решит этот тикет (парное программирование, передача тикета другому и т.д.) без всякого канбана.
Если шанс у менее организованной команды пользоваться канбаном?

К сожалению, не наш случай, человек висит, а люди делают свои тикеты. В скраме эта проблема частично решалась командной ответственностью,
то есть зависание ставило под угрозу спринт, поэтому "зависший" начинал активно обсуждать свою проблему с командой, команда тоже заинтересована не сорвать спринт.

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

[Андрей Бибичев]

А вы измеряете Lead Time по задачам? По идее, в Kanban всё должно быть
нацелено на оптимизацию Lead Time. Например, ребята из нижегородского
Intel рассказывали, что у них это делается так: каждый день в
определенное время специальный человек подходит к Taskboard и
пробивает по дырке на каждой задачке, которая висит в "In Progress".
Таким образом, на каждой задаче к тому времени, когда она доедет до
правого края, т.е. будет закончена, образует определенное количество
дырок - это её Lead Time в рабочих днях. Дальше вы отслеживаете
выбросы - задачи, которые заняли особо много времени, и совместно
(например, на ретроспективах) решаете что с этим делать (как можно
уменьшить Lead Time по подобного рода задачам). Чтобы была
дополнительная информация полезно: на каждой фазе отмечать
ответственного за прохождение задачки через эту фазу, дырки по разным
фазам клепать в разных углах бумажки. Т.е. Kanban сводится к
оптимизационной задаче: WIP <= limit, Lead Time -> min, которую должна
решать команда :)
А.

[Alimenkou Nikolay]

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

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

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

[Pavel Aksonov]

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

2009/12/17 Alimenkou Nikolay <lumii.su...@gmail.com>

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

[Андрей Бибичев]

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

Дык, надо брать не среднее (или не только среднее) по задачам, а MAX
по задачам.
:)

[Alimenkou Nikolay]

Это классическая проблема статистического анализа. Если берется
максимум, то одна плохо (невовремя) сделанная задача убивает
показатель метрики напрочь. Cycle Time считается именно как среднее, а
не абсолютное значение. Интервал подсчета может быть выбран
произвольно (к примеру неделю). Метрику максимума можно вести как
вспомогательную, тогда она вам покажет проблемные зоны в разбиении
задач и их недооцененной сложности.

[Андрей Бибичев]

> Это классическая проблема статистического анализа. Если берется
> максимум, то одна плохо (невовремя) сделанная задача убивает
> показатель метрики напрочь.

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

А для предсказания "через сколько будет готова эта фича/исправлен данный баг" или отслеживания "расслабленности команды" лучше использовать даже не среднее, а медиану. Причем медиану с учетом кластеризации задач по категориям сложности (кластеризацию, опять же, можно провести, поднакопив статистики).

Но это всё уже не так важно - главное начать собирать информацию по Lead Time каждого таска. А уж воспользоваться этой информацией - не проблема (была бы голова на плечах :)).

[Андрей Бибичев]

> Сейчас у нас стадия маааленьких баг-фиксов и текстовых изменений

> поэтому один день "в разработке" это уже достаточно неплохое "зависание"

А если дырки прокалывать каждый час или два? Т.е. измерять не в днях, а в часах?

И, может, митинги проводить пару раз в день?

[Pavel Aksonov]

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

2009/12/17 Андрей Бибичев <bibi...@gmail.com>

--

[Ant Bevzuk]

Мы так и делаем. Дырявим в конце каждой парной сессии, которые длятся
1.5 - 2 часа.