КАНБАН: пример естественного применения

Автор: Александр Якима (www.enter-agile.com)


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

Итак, описание кейса:

- Стадии (фазы, этапы) работы объективно существуют как часть формализованного процесса - диктуются заказчиком.

- Процесс почти строго последовательный

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

- Эстимирование объективно осложнено: система очень большая, каждый второй work item несет в себе много нового и неизвестного

- План работы может меняться произвольно - новые важные work items могут появляться в любое время

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

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

А как это лучше всего сделать? Точно! Ограничить работу в прогрессе и аккуратно следить за "проседанием" задач на индивидуальном уровне.

Поток ценности выглядит приблизительно так:


Соответственно, вот пример Канбан-доски для этого процесса:

И стало действительно лучше жить. Разработчик не берет больше одного айтема в разработку (за исключением, когда предыдущий ушел в приемочное тестирование, которое делается удаленной командой) - тоесть формулировка WIP Limit для этого случая звучит немножко нетривиально: "Не более одной задачи в строке таблицы, за исключением 2-х задач, одна из которых на этапе приемочного тестирования". Стало реально трэкать, что и как происходит. При этом, когда новый work item приходит под высочайшим приоритетом с легким движением руки Продакт-оунера, команда убирает одну из текущих задач в "отстойник" и высвобождает слот в пользу новой задачи. Естественно, лечге трэкать потери при постоянном изменении плана и Продакт-оунер принимает более осмысленные решения.

Патчи идут на продакшн-среду каждую неделю и каждую же неделю проводиться то, что команда называет "Kanban status meeting" - что-то похожее на демо + план новых задач (которые можно планировать) вместе с Продкат-оунером. Ежедневный утренний стэнд-ап для определения внутреннего статуса работы команды тоже никуда не исчез. Только проводит его теперь Kanban-мастер.

Наконец, очень важно отметить, что модель хорошо сработала именно потому, что процесс "сторго поэтапный" - данность в связи со спецификой и стилем работы заказчика. Однако, значительно эффективнее (даже в этом самом случае) было бы применять модель D-B-T (Define-Build-Test), в которой нет строгих фаз и "водопадоподобности", а наоборот - микроциклы D-B-T много раз прокручиваются, пока не получается то, что нужно. Но об этом в последующих постах...

No comments:

Post a Comment

 
Powered by Blogger