День 263. Канбан (III)

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

ПРИОРИТЕТЫ

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

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

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

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

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

Было принято решение вообще отказаться от оценки задач — это высвободило дополнительные ресурсы и с учетом прозрачности очереди работ, ситуация стала меняться в лучшую сторону.

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

ЧАСТЫЕ РЕЛИЗЫ

Канбан избавляется от ограниченных во времени итераций и вместо этого рассинхронизирует деятельность по расстановке приоритетов, разработке и поставке. Каденция для каждой из них устанавливается и корректируется естественным образом. Однако Канбан не отказывается от понятия «регулярная каденция». Канбан-команды по-прежнему с заданной частотой выдают версии продукта, предпочитая короткие интервалы. Метод тоже работает в соответствии с «Принципами манифеста гибкой разработки». Однако Канбан старается избегать любых крайностей, связанных с искусственной установкой временны́х рамок для задач.

ОЦЕНКА ЗАДАЧ И РАССТАНОВКА ПРИОРИТЕТОВ

Обратим внимание на следующие пункты:

1. Приведенный пример с индийским офисом Microsoft показал, что необходимо соблюдать баланс между «полезной» работой по выдаче бизнес-ценности (непосредственно разработкой и тестированием) и дополнительными расходами по оценке задач и груммингу бэклога.

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

2. Многие команды используют покерное планирование — когда команда обсуждает задачу и каждый разработчик оценивает ее в условных единицах (стори-пойнтах) выбирая соответствующую карточку (оценки соответствуют последовательности Фибоначчи: 0, 0.5, 1, 2, 3, 5, 8, 13)

После того как все выкинули свои карточки — они открываются и выбирается средняя оценка. При этом рекомендуется следовать следующим правилам:

— если оценки сильно отличаются (присутствуют не только соседние числа, например: 1, 2, 2, 3) — проводится дополнительное обсуждение, поскольку велика вероятность того, что задача была понята неправильно. В этом случае высказываются те, кто дал крайние оценки (максимальную и минимальную) и пытаются убедить других. После этого проводится дополнительное голосование

— если оценки отличаются незначительно (то есть все соседние и при этом нет большинства) я ставлю среднее — например в случае 2, 3, 3, 2 — 2.5

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

Вот, например, шкала одной из моих команд:

3. в отличие от SCRUM-команды канбан-команды могут осуществлять расстановку приоритетов по запросу или по ситуации.

Как у нас в piano: ранее наш процесс был построен ближе к SCRUM, то есть мы имел двухнедельные спринты, проводили ретроспективы и планирования в заданный день и не брали задачи в работу, если они пришли во время спринта, но затем перешли к Канбану — отказались от фиксированных спринтов, сделали один общий бэклог, который сортируется нами и продукт оунерами и проводим планирования и оценки по необходимости (когда, например, остается мало задач в WIP и нужно оценить и взять в работу еще, либо когда приходит новая фича и ее нужно разбить на задачи и оценить). В таком случае (при Канбане) процесс более гибкий — мы можем взять любую задачу (если она горит) в работу прямо сейчас — не дожидаясь следующего спринта.  

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

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

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