опубликовано: 25.11.2018
Суть: Kanban — это не просто доска, а метод улучшения качества сервиса.
Чтобы начать использовать Kanban, нужно:
Выводы из книжки Хенрика Книберга:
Kanban опирается на парадигмы Lean: управление изменениями, поток, вытягивающая система.
Принципы Kanban:
На доске должно быть две колонки для беклога: сделать и план. Сделать это классический беклог. План, это то что мы договорились сделать. Т.е. у нас появляются отложенные обязательства.
На доске бывают колонки для спецов, например, Переводчик, Редактор или Программист, тестировщик. Эта колонка должна быть разделена на две: в работе и готово. Потому что то что переводчик закончил свою часть, еще не означает, что редактор начал свою.
Есть беклог с историями, которые берутся для спринта и декомпозируются на задачи. Задачи переносятся на доску.
Это не задачи, а рабочие элементы, над которым нужно совершить работу, чтобы сдвинуть дальше по процессу. Без WIP лимиты доска не является канбан доской. Мы ограничиваем количество работы на стадии процесса. Без ограничений появляется множество заблокированных задач, которые не будут двигаться, потому что люди просто будут брать другие. Если ограничение будет, то люди будут думать что брать, какие будут блокировки, и т.п. Элементы будут браться по одной и обрабатываться совместно. Через какое-то время совместная работа станет нормой, люди будут помогать другим людям и появятся кроссфункциональные команды.
Закон Литла: среднее время ожидания = размер очереди / скорость обслуживания
. И мы можем это видеть на доске. Изменяя лимит, мы влияем на поток.
Работа с правилами. С ними нужно работать, собирать фидбек и менять. Доска не статично, а меняется со временем. Например, то как мы выбираем задачи из беклога, тоже правило. Если Scrum говорит, что беклог должен быть приоретизирован, то Kanban говорит, что это зависит от ситуации. На доске вешаются листочки с критериями DoD и правилами выбора.
Если построить гистограмму по скорости прохождения элемента по процессу, мы можем увидеть пики, которые, возможно, являются разными типами работы. Т.е. Виды работ мы извлекаем из статистики работы. Из этого мы можем сказать, что на основании стат данных, задачи такого-то типа делаются за такое-то время. Теперь мы на отдельном листочке можем описать критерии, по которым мы понимаем тип задачи.
На основе этих же данных можно посмотреть наше отношение к задаче и сделать SLA для разных типов важности задач.
Чтобы отразить это на доске, нужно ввести горизонтальные линии, а чтобы все задачи вдруг не стали срочными, добавить лимиты. Сумма лимитов горизонтальных линий должна быть равна сумме лимитов столбцов. Приоритет на Kanban доске строиться сверху вниз и справа налево.
Разрисуем нашу доску по цветам и по каждому цвету будем собирать статистику раз в неделю по кол-ву листочков.
На этом строиться накопительная диаграмма потока (CFD). Диаграмма показывает Lead Time, WIP лимит и пропускную способность. Видно, как мы можем влиять на наш процесс по теореме Пифагора. Если меняем угол или катет, меняем пропускную способность.
По гистограмме скорости прохождения элемента можно понять что происходить со временем производства. Делаем усредненный тренд и если он идет вверх, значит время производства увеличивается, если вниз — ускоряется. Можно сделать порог, после которого необходимо пойти поговорить с командой.
Рабочий процесс состоит из работ и фаз ожиданий. Мы можем посчитать длину по времени фазы ожидания и длину работы. Из этого выделяется эффективность потока (FE). FE = Время работы / время производства
.
Завязаны на частоту дней
Частота абсолютна разная
Выделяется человек, который проходит по доске справа налево и задаем вопросы. Что нужно сделать, чтобы сместить элемент и можем ли мы чем-то помочь?
В какой-то момент образуется вакуум, мы все закрыли. Это значит что мы должны взять новые задачи. В Scrum задачи выбирает Product Owner, но это не всегда возможно и их может быть много. Поэтому собираем всех вместе и выбираем. Желательно иметь фасилитатора.
Заранее договариваемся о приемке задач на поставку. Если у на CD, то такие собрания не нужны.
Это куча отделов(сервисов) в компании. Одни сервисы оказывают услуги другим сервисам. На эти услуги мы накладываем SLA, о том какие могут быть запросы и сколько будут выполняться, и SLE, с ожиданиями заказчика. Другими словами, у каждого сервиса есть предназначение(Fitness For Purpose). Нужно стремиться к стыковке SLE и SLA.
Собираемся с заказчиками о том что мы сделали, что они ожидают от нас с точки зрения обслуживания. Рекомендуется проводить раз в 2 недели.
Собираются представители сервисов, обсуждают как они между собой взаимодействуют.
Берем диаграммы от разных сервисов и строим цепочки, чтобы понять что нужно делать, чтобы глобальный сервис работал вовремя.
Как собрать конфигурацию сервисов в рамках компании и как планировать ее работу.
Применение канбановских принципов в зрелом акрам-процессе.
Kanban — метод улучшения качества сервиса.
Я консультирую о том о чем пишу, связаться со мной можно через telegram @aladmit или по почте [email protected]