Комментарии 5
Пошаговое применение практик в командах принесло существенные улучшения. Сравнивая показатели через год, мы видим, что скорость поставки ценности от команд улучшилась почти в 2 раза – Lead Time со 175 дней сократился до 93. Пропускная способность выросла почти в 5 раз и составила 321 вместо 65 задач.
Здесь стоит сделать ремарку и уточнить, что кроме существенного улучшения скорости, также повысилось качество декомпозиции задач.
Ваша пропускная способность и скорость поставки выросли от правильной декомпозиции задач и от того, что в эту выборку попали "легкие" задачи, а остальное лишь рюшечки.
Мне вот интересно, а вы лично, как agile-коуч, участвовали в декомпозиции?
Спасибо за вопрос. Улучшение метрик связано не только с декомпозицией задач. Если обратить внимание на первый график, то видно, что половина ранее существующих задач была адекватного размера и не нуждалась в дополнительном редуцировании. Вторая же половина представляла из себя смесь задач непредсказуемого размера, различные иерархические сущности для хранения более мелких подзадач, забытые задачи без должного фокуса внимания на них. Именно на вторую группу и был направлен комплекс мер, включая декомпозицию.
Как Agile-коучи мы не только принимаем непосредственное участие в декомпозиции задач, но и централизованно определяем правила иерархии проектов в командах, а также мониторим корректность применения этих правил.
В нашей практике мы стараемся принимать решения и делать выводы исходя из накопленной информации и собранной фактуры. Мы работаем с потоком задач и его состав далеко не всегда однороден. Могут встречаться "легкие задачи", а могут быть и "тяжеловесные". Основная задача команды взять в работу самое ценное для организации независимо от размера.
Как Agile-коучи мы не только принимаем непосредственное участие в декомпозиции задач, но и централизованно определяем правила иерархии проектов в командах, а также мониторим корректность применения этих правил.
Вот это "централизованно определяем правила" как раз понятно и мне не интересно. Но я не видел еще коуча, непосредственно участвующего в декомпозиции. А ваше использование "мы" вместо "я" оставляет место для сомнений.
Сразу скажу, что некоторые инструменты и практики канбан метода мне импонируют, но статьи о нем прям как под копирку, не интересно скажем так.
Далее вопросы :
У вас было упоминание что команда смотрит метрики своей производительности, как вы к этому пришли ну и каково было объяснение этого команде, например если я инженер моя метрика это контрибюты в гитлаб и качественный код, у инженера качества это актуальные АТ и сведение к нулю багов в проде. Какую проблему для себя я решу этой метрик ой производительности, ведь код написан, задеплоен, это пахнет больше KPI
Были ли у вас в практике при построении досок с кучей статусов, а если в неё включать буферные статусы, то их действительно будет куча, отторжения на стороне команд, типа jira development, нафиг все это надо, как объясняли ценность именно для команды этих статусов, тут добавим условие что поинт о том что это визуализация полезна для наших заказчиков их не волнует, вот ты коач, ты иди и визуализируй, отчитывайся как хочешь им
Вот вы улучшили цифры, а ценности это точно больше принесло или вы работаете на уровне команды и её производственные показатели главное, даже если бизнес приносит абсурдные идеи?
Спасибо большое за ваш комментарий и вопросы. Действительно, может сложится впечатление, что некоторые статьи похожи друг на друга. В рамках Канбан-метода есть 6 основных групп практик, которые можно использовать для улучшения текущего процесса поставки ценности для клиента и/или для решения отдельных проблем. Предположу, что подход к реализации практик может быть похож, но может меняться контекст команд/организаций, последовательность действий при применении и масштаб эффекта.
В Канбан-методе применяется эволюционных подход. Практики направлены не только на получение определенных выгод, но и на повышение зрелости команд (Модель КММ). Обычно, в самом начале пути, команды находятся на "рассеянном" уровне зрелости, когда каждый сам за себя. Группа отдельных экспертов в своей области. Далее команда эволюционирует на "командоцентричный" уровень, когда приходит понимание, что нет "моих задач", а есть задачи команды. Все работают над тем, чтобы завершить задачи совместными усилиями с максимально возможной скоростью. Здесь появляются общие метрики потока: Какие задачи мы делаем? Как быстро? Сколько в штуках и какого типа задач мы делаем за промежуток времени?
Сам подход не направлен на измерение отдельных людей и их производительности. Он направлен не на людей, а на процесс. Мы оцениваем возможности "сервиса", ищем узкие места в процессе, повышаем предсказуемость и равномерность поставки ценности.
Конкретно для вас, как части команды, появится понимание как быстро и много делает вся команда, куда нужно приложить командные усилия, чтобы стало лучше.
Из опыта: как только метрики в виде скорости или количества задач появляются в KPI - команды интуитивно начинают их читерить.В моей практике был опыт построения рабочего процесса с буферными этапами в виде "Анализ" и "Анализ готов", "Разработка" и "Разработка завершена" и т.д. Команде интересно было показывать, на каком этапе скапливается работа и есть ли простои, особенно на этапах взаимодействия с другими командами и заказчиками. В последующем, мы использовали статистику "простоев" между этапами, чтобы аргументировано разрабатывать правила для приемки задач и общения с приемщиками, для разработки правил перехода задач из одного этапа в другой (DoD и DoR). Кроме того, можно получить дополнительную статистику по реальному времени выполнения задачи (touch time) и сравнить с общим временем выполнения задачи в вашем сервисе (lead time), а на выходе получить метрику эффективности потока (Flow efficiency).
Про "нафиг всё это надо" мы объясняли через ценность, что мы можем получить на выходе, если начнем собирать эти цифры. Конкретный пример: У команды зависали задачи на приемке и было непонятно то ли команда долго копается, то ли заказчики долго реагируют. Когда собрали фактуру в виде метрик по буфферному этапу, то смогли договориться о новых правилах с заказчиками за сколько они должны принимать задачу, когда мы их уведомляем и т.д.Чтобы бизнес не приносил "абсурдные идеи" мы стали применять по всей организации скоринговые модели, которые позволяют оценить реальную ценность от задачи. Стратегия организации даёт понимание основных метрик, на которые мы должны повлиять. Эти метрики мы заложили в параметры скоринга задач. После этого, все задачи выстроились в прозрачный список, где сверху - самое актуальное и ценное, а снизу - менее важное и недостаточно ценное для компании.
Т.е. тут двухсторонние отношения по повышению прозрачности: заказчики показывают, что действительно важно, а исполнители - сколько они обычно делают и в какие сроки.
Как Канбан-метод повлиял на команды банка