Comments 2
Появилось впечатление, что на проекте существует какое-то кол-во работ которое не связано никак с потребностями/ценностью для заказчика и странно было видеть WIP в %.
Что касается применения CFD для отслеживания ценности… Не знаю даже. CFD — отличный визуальный инструмент для отслеживания здоровья kanban-проекта который объясняется за 2 минуты и действительно позволяет по картинке сделать вывод о том что и где подкрутить (например youtu.be/eo2uv8avEsU). То, что описано у Вас я не сильно понимаю как и зачем применять на проектах. Есть доска с ежедневной работой команд(-ы) которую нужно оптимизировать по lead time, wip и т.д., а есть roadmap в котором запланированы значимые для Заказчика проектные достижения. Доска и дорожная карта синхронизируются периодически и рассказываются Заказчику. Зачем их скрещивать не понятно.
Что касается применения CFD для отслеживания ценности… Не знаю даже. CFD — отличный визуальный инструмент для отслеживания здоровья kanban-проекта который объясняется за 2 минуты и действительно позволяет по картинке сделать вывод о том что и где подкрутить (например youtu.be/eo2uv8avEsU). То, что описано у Вас я не сильно понимаю как и зачем применять на проектах. Есть доска с ежедневной работой команд(-ы) которую нужно оптимизировать по lead time, wip и т.д., а есть roadmap в котором запланированы значимые для Заказчика проектные достижения. Доска и дорожная карта синхронизируются периодически и рассказываются Заказчику. Зачем их скрещивать не понятно.
Не совсем так, никаких не несущих ценности работ в проекте нет, конечно.
Здесь речь о том, что отслеживать метрики и здоровье проекта имеет смысл на уровне того, что в методе называют customer recognizable work items, а не технических задач в командах. CFD в таком случае показывает именно здоровье проекта, в отличие от CFD на уровне задач, которая, конечно, показывает поток, только пользы в нём гораздо меньше. И хорошая СFD на уровне технических задач команды очень мало говорит о здоровье поставки ценности клиенту сервиса.
Оптимизация на уровне команды, отдельных задач, это локальная оптимизация. А Канбан-метод (и не только он) учит нас, что локальная оптимизация чаще всего не приносит пользы для цепочки поставки ценности. Канбан систему имеет смысл строить end2end и смотреть на систему и поток в целом.
Видео хорошее для общего понимания. Чтобы научиться видеть паттерны на диаграмме, придётся потренироваться.
подход с двумя досками, который вы описываете, в методе называется «двухуровневая визуализация». Может быть полезной, но с ней довольно тяжело работать, в большинстве инструментов синхронизировать придётся вручную.
Здесь речь о том, что отслеживать метрики и здоровье проекта имеет смысл на уровне того, что в методе называют customer recognizable work items, а не технических задач в командах. CFD в таком случае показывает именно здоровье проекта, в отличие от CFD на уровне задач, которая, конечно, показывает поток, только пользы в нём гораздо меньше. И хорошая СFD на уровне технических задач команды очень мало говорит о здоровье поставки ценности клиенту сервиса.
Оптимизация на уровне команды, отдельных задач, это локальная оптимизация. А Канбан-метод (и не только он) учит нас, что локальная оптимизация чаще всего не приносит пользы для цепочки поставки ценности. Канбан систему имеет смысл строить end2end и смотреть на систему и поток в целом.
Видео хорошее для общего понимания. Чтобы научиться видеть паттерны на диаграмме, придётся потренироваться.
подход с двумя досками, который вы описываете, в методе называется «двухуровневая визуализация». Может быть полезной, но с ней довольно тяжело работать, в большинстве инструментов синхронизировать придётся вручную.
Sign up to leave a comment.
Накопительная диаграмма потока (CFD) как индикатор здоровья вашего проекта