Flow efficiency что это
Kanban.club
Первое, с чего стоит начать, чтобы измерять эффективность потока, очевидно, что нужен поток. Упрощенно, поток можно разделить на следующие этапы:
Обратите внимание на первый пункт: это список работ, где есть элементы работы, которые не надо делать никогда. И здесь нужно учитывать контекст, где ваш поток находится. Если это ресторан, то людей, которые находятся в очереди на входе в ресторан вы не обязаны обслужить всех и более того, можете выбирать кого обслужить, а кого нет. Например, соответствует вашему дресс-коду или нет. (вспоминаем про конкурс красоты ) Если вы техническая поддержка или служба оперативного реагирования, то вам нужно обслужить все запросы и как можно скорее. В этом случае, у вас нет пункта backlog и вся работа сразу попадает в To Do, а это значит, что вы по ней уже дали обещание (SLA договоренность об уровне сервиса) и время для клиента начинает тикать моментально.
Давайте подумаем, а как мы вообще начали думать об эффективности потока?
Бизнес всегда думает об эффективности, и первая эффективность которой легче всего управлять — это эффективность использования ресурсов. Т. е. мы должны следить, чтобы у всех людей обе руки были заняты и чтобы все станки в цеху, столики в ресторане, операторы в колл-центре и т. д. были в работе 100% (или близко к этому) времени, в реальности получается 75-80%, остальное уходит на перерывы, покурить, ненужные встречи и т. д.
Что мы получаем в итоге: у нас все люди заняты и много недовольных клиентов, потому, что для них время ожидания в очереди или в процессе обслуживания очень большое, которое их явно не устраивает.
Обычно, следующий шаг — это увеличить количество людей (аналитиков, поваров, кассиров, программистов и т. д.), так как кажется что именно в этом вся проблема. СТОП. Если вы пришли к этой точке, то это тот самый момент, когда пора подумать, а что же у нас с эффективностью потока?
Формула подсчета Эффективности потока
Подсчет эффективности потока делается следующим образом:
Эффективность потока (в %) = Время работы / (Время работы + Время ожидания)
Где,
Время работы = Времени, когда карточка находилась в колонках вида “В работе” (т. е. когда создавала ценность) минус время, когда в них карточка была заблокирована
Время ожидания = Время блокировки плюс Время, когда карточка находилась в колонках вида “Готово”, “Закончено”, “Сделано” плюс Время в бэклоге (если наши обязательства распространяются на колонку Бэклог)
Обычная эффективность около 15%, т. е. 85% времени с элементом работы никто не занимался.
Чтобы подсчет эффективности потока стал возможен нам потребуется визуализация, как минимум в виде канбан-доски и сбор статистики по выполненным элементам работы.
Эффективность ресурсов и эффективность потока — это две стороны одной медали. Мы привыкли фокусироваться на активную составляющую нашей работы: написание автотестов, обучение сотрудников, выстраивание devops трубы, качество приготовляемой еды на кухне, скорость работы кассира и т. д. Это все правильно, но работа только на этим может быстро перестать давать положительный эффект и каждым новым уровнем улучшения стоит дороже, но и есть темная сторона: это время, когда мы просто ждем и природа этого времени может быть разной: зависимости, смена приоритетов, ожидание следующего этапа, блокировки и т. д.
То, что задача находится в работе и то, что над ней кто-то работает не одно и тоже, и Эффективность потока показывает как часто это бывает правдой.
Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов
Для начала посмотрим о чем нам говорит закон Литтла:
Т. е. при сохранении скорости потока (сколько элементов работы выходят из нашей системы в единицу времени), мы можем сократить среднее время выполнения за счёт того, что сократим количество одновременно выполняемой работы. К чему это приведет: заказчики встанут в очередь и кому-то из них нужно говорить “нет” или “подожди”, а некоторые сотрудники будут простаивать, ведь при меньшем количестве работы ее может на всех не хватить и это хорошо.
Еще видео о ловушке утилизации ресурсов
flow efficiency
Смотреть что такое «flow efficiency» в других словарях:
Flow measurement — is the quantification of bulk fluid movement. Flow can be measured in a variety of ways. Positive displacement flow meters acumulate a fixed volume of fluid and then count the number of times the volume is filled to measure flow. Other flow… … Wikipedia
Flow (psychology) — Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity. Proposed by positive psychologist Mihály… … Wikipedia
Flow chemistry — In flow chemistry, a chemical reaction is run in a continuously flowing stream rather than in batch production. In other words, pumps move fluid into a tube, and where tubes join one another, the fluids contact one another. If these fluids are… … Wikipedia
Flow coefficient — The flow coefficient of a device is a relative measure of its efficiency at allowing fluid flow. It describes the relationship between the pressure drop across an orifice, valve or other assembly and the corresponding flow rate.Coefficent of… … Wikipedia
Cross-flow turbine — Cross flow turbine. Image credit; European Communities, Layman s Guidebook (on how to develop a small hydroelectric site) A cross flow turbine, Banki Michell turbine, or Ossberger turbine[1] is a water turbine developed by the Australian Anthony… … Wikipedia
Algorithmic efficiency — In computer science, efficiency is used to describe properties of an algorithm relating to how much of various types of resources it consumes. Algorithmic efficiency can be thought of as analogous to engineering productivity for a repeating or… … Wikipedia
Reverse-flow cylinder head — A reverse flow or non crossflow cylinder head is one that locates the intake and exhaust ports on the same side of the engine. The gases can be thought to enter the cylinder head and then change direction in order to exit the head. This is in… … Wikipedia
Volumetric efficiency — in internal combustion engine design refers to the efficiency with which the engine can move the charge into and out of the cylinders. More correctly, volumetric efficiency is a ratio (or percentage) of what volume of fuel and air actually enters … Wikipedia
Data-flow analysis — is a technique for gathering information about the possible set of values calculated at various points in a computer program. A program s control flow graph (CFG) is used to determine those parts of a program to which a particular value assigned… … Wikipedia
Air flow bench — An air flow bench is a device used for testing the internal aerodynamic qualities of an engine component and is related to the more familiar wind tunnel. Used primarily for testing the intake and exhaust ports of cylinder heads of internal… … Wikipedia
Material flow analysis — 3R Concepts Waste Disposal Hierarchy Reduce Reuse Recycle Barter Dematerialization Downcycling Dumpster diving Ecode … Wikipedia
flow efficiency
1 flow efficiency
2 flow efficiency
3 flow time efficiency
См. также в других словарях:
Flow measurement — is the quantification of bulk fluid movement. Flow can be measured in a variety of ways. Positive displacement flow meters acumulate a fixed volume of fluid and then count the number of times the volume is filled to measure flow. Other flow… … Wikipedia
Flow (psychology) — Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity. Proposed by positive psychologist Mihály… … Wikipedia
Flow chemistry — In flow chemistry, a chemical reaction is run in a continuously flowing stream rather than in batch production. In other words, pumps move fluid into a tube, and where tubes join one another, the fluids contact one another. If these fluids are… … Wikipedia
Flow coefficient — The flow coefficient of a device is a relative measure of its efficiency at allowing fluid flow. It describes the relationship between the pressure drop across an orifice, valve or other assembly and the corresponding flow rate.Coefficent of… … Wikipedia
Cross-flow turbine — Cross flow turbine. Image credit; European Communities, Layman s Guidebook (on how to develop a small hydroelectric site) A cross flow turbine, Banki Michell turbine, or Ossberger turbine[1] is a water turbine developed by the Australian Anthony… … Wikipedia
Algorithmic efficiency — In computer science, efficiency is used to describe properties of an algorithm relating to how much of various types of resources it consumes. Algorithmic efficiency can be thought of as analogous to engineering productivity for a repeating or… … Wikipedia
Reverse-flow cylinder head — A reverse flow or non crossflow cylinder head is one that locates the intake and exhaust ports on the same side of the engine. The gases can be thought to enter the cylinder head and then change direction in order to exit the head. This is in… … Wikipedia
Volumetric efficiency — in internal combustion engine design refers to the efficiency with which the engine can move the charge into and out of the cylinders. More correctly, volumetric efficiency is a ratio (or percentage) of what volume of fuel and air actually enters … Wikipedia
Data-flow analysis — is a technique for gathering information about the possible set of values calculated at various points in a computer program. A program s control flow graph (CFG) is used to determine those parts of a program to which a particular value assigned… … Wikipedia
Air flow bench — An air flow bench is a device used for testing the internal aerodynamic qualities of an engine component and is related to the more familiar wind tunnel. Used primarily for testing the intake and exhaust ports of cylinder heads of internal… … Wikipedia
Material flow analysis — 3R Concepts Waste Disposal Hierarchy Reduce Reuse Recycle Barter Dematerialization Downcycling Dumpster diving Ecode … Wikipedia
Agile-метрики команд. Часть 2. Хорошие метрики
Burn-up Chart
Что это: показывает как вы съедаете скоуп (объем) к дате или же, наоборот, к какой дате будет сделан этот объем скоупа.
Картинка с https://spin.atomicobject.com/2016/03/31/burn-up-charts/
Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?
Или что будет сделано к Рождеству?
В Agile мире мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет. Поэтому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.
End-to-end time to market (Lead time)
Что это: эта метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.
Часто в разработке команды измеряют то, как быстро они делают саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.
Однако намного интереснее то, сколько времени прошло в целом от идеи до реализации. И вот почему:
Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу
А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика 🙂
Эффективность потока (Flow Efficiency)
Любая работа – это совокупность активных стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.
Source https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/
Например, возьмем упрощенный процесс разработки с точки зрения задачи:
Проработка деталей — Разработка — Тестирование — Выпуск
В такой цепи “задача” будет находиться в активном состоянии тогда, когда над ней будет проводиться работа. Например, когда программист пишет код. Как только он закончил, то с точки зрения задачи активная фаза закончилась, то есть перешла в стадию “ожидание тестирования”. Тестировщик приступит к работе тогда, когда освободится от других задач.
Если вы считаете время, которое тратится на “работу” над задачей, то: есть активное время, а так же время, которое задача проводит в ожидании. И вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.
Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%
Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.
Количество элементов в беклоге
Что меряет: меряет количество элементов в бэклоге 🙂
Зачем мерять? Чтобы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.
Как за любым складом за бэклогом нужно ухаживать, пересматривать, оценивать, чистить и инвентаризировать.
Чем больше ваш бэклог – тем меньше вы понимаете, что в нем хранится и тем меньше его фактическая актуальность
Более того, чем больше всех элементов, тем больше времени тратится на уход за ним, а также меньше прозрачность работы в нем.
Нет цифры, которая бы идентифицировала предел 🙂 Это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂
Срок жизни элемента беклога
Предыдущая метрика тесно связана с этой метрикой : чем старее задачи в беклоге, тем меньше смысла они имеют.
Старость беклога обычно гворит о следующих проблемах:
Чем меньше срок жизни – тем понятнее контент беклога, проще с ним работать и повышается его актуальность.
Эволюция Definition of Done
Именно увеличение критериев готовности отлично отображает, насколько растет техническая осознанность команды, насколько быстро вы можете делать изменения, насколько быстра обратная связь и насколько вы близки к клиенту.
Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали больше Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.
Портал №1 по управлению цифровыми
и информационными технологиями
Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо.
И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке.
К примеру, вот что написано в словаре книжки «Essential Kanban Condensed» за авторством Д. Андерсона и А. Кармайкла:
Flow Efficiency — the ratio of the time spent working on an item (Touch Time) to the total Time in Process; measured in percentage.
Touch Time — the sum of all the times during which a work item is actively being worked on (excluding wait times; e.g., being held in stock or in queues; measured in units of time.
Time in Process — the total time that a work item remains in a state under consideration; measured in units of time. Alternatives: Lead Time (when referring to the time in process from the commitment to delivery point).
Книга «DevOps Handbook» (авторы Дж. Ким, Дж. Хамбл, П. Дебуа, Дж. Уиллис) в целом повторяет ту же мысль:
In the Lean community, lead time is one of two measures commonly used to measure performance in value streams, with the other being processing time (sometimes known as touch time or task time).
Whereas the lead time clock starts when the request is made and ends when it is fulfilled, the process time clock starts only when we begin work on the customer request — specifically, it omits the time that the work is in queue, waiting to be processed.
Because lead time is what the customer experiences, we typically focus our process improvement attention there instead of on process time. However, the proportion of process time to lead time serves as an important measure of efficiency—achieving fast flow and short lead times almost always requires reducing the time our work is waiting in queues.
Итак, раз учёные рекомендуют, нужно использовать. Вернёмся к формуле, рассмотрим сначала знаменатель.
Как посчитать Time in Process? Казалось бы, всё просто: это же то же самое, что Lead Time (намекают нам авторы «Essential Kanban Condensed» и «DevOps Handbook»). Поэтому если в нашей производственной системе чётко определено событие «Start», начало работы, а также событие «Done!», завершение работы, то достаточно вычесть из второго первое, получим Time in Process. Так ли это? Похоже, что нет. Таким расчётом мы получим астрономическое время, которое задача провела в потоке. Если наш поток работает круглосуточно — прекрасно, можно использовать. Однако в большинстве случаев сотрудники в ИТ работают только 8 часов в день, и только в рабочие дни. Если не учитывать доступное рабочее время, то мы легко можем получить, что задачу довольно оперативно сделали за три дня, потратив, скажем суммарно 24 рабочих часа, но в потоке она провела три календарных дня, то есть 72 часа. Эффективность потока по формуле — 33,3%, по факту — 100%. Ерунда. И это мы ещё не рассматриваем ситуацию перехода через выходные.
Предположим, что мы хотим учитывать доступное рабочее время. Если бы в нашем потоке был один исполнитель, всё было бы просто: это его рабочий календарь и есть. Но во всех известных мне потоковых системах исполнителей немного больше. Чей календарь учитывать, если аналитики располагаются в Новосибирске, разработчики — в Москве, а инженер по тестированию работает на полставки, потому что у неё ребёнок маленький? Рабочий график у всех разный. Похоже на тупичок. Применив метод «костыли и договорённости» из него, конечно, выбраться можно, но это уже будет не расчёт, а оценка.
Теперь рассмотрим числитель. Требуется рассчитать Touch Time, и здесь всё ещё хуже. В идеальном мире сотрудники, взяв из входящей очереди задачу, не отвлекаются, а выполняют её от начала и до конца, после чего перемещают в выходящую очередь (см. Lean, конвейер). В реальном мире между событиями «Взял» и «Отдал» есть не только работа, но ещё и консультации коллег по другим вопросам, небольшая оперативка команды, ситуация «ой, пришлось переключиться на устранение дефекта, потому что это экспедит», кусочек фейсбука и, чего уж там, обед. Мне не известно ни одной команды, где фиксировалось бы время работы над задачей по таймеру. Значит, смотрим на изменения статусов в Jira и, фактически просто убираем из расчёта время в очередях. Значит, огрубляем. Значит, получаем ерунду, а не оценку эффективности потока. Чтобы понять масштаб бедствия (и категорическую непригодность данного метода) можно выполнить простой альтернативный расчёт: из общего ресурса команды (скажем, N человек х 8 часов в день х 5 рабочих дней) вычесть время, списанное на задачи, с которыми работали за данную неделю. Получим противоположность Touch Time — время, которое было доступно, но ушло непонятно куда. Вот диаграмма Flow Efficiency одной из команд со значениями, рассчитанными по двум способам:
Несложно заметить, что результаты расчёта отличаются в 2-5 раз (не на единицы и не на десятки процентов). Несложно также предположить, что эффективность в 90% и более вряд ли имеет место быть в реальности.
И это мы ещё не рассматриваем ситуацию, при которой над данной задачей одновременно работают несколько исполнителей. А такое в ИТ бывает (см. front/back, например). Чьё тогда время учитывать в Process Time — первого, второго, обоих вместе, самого долгого, или того, кто постарше?
Получается, что ни числитель, ни знаменатель этой простой формулы толком не посчитать. А значит, и результат деления не имеет большого смысла. Как же тогда быть с умными книжками?
Прошу понять меня правильно: я за работу по потоку, обеими руками. Я за измерение эффективности. Я даже с Jira готов мириться, если уж так рассудить.
Метрика эффективности потока — мощный инструмент. Десятки раз я проводил очень простое, но очень полезное упражнение с разными командами: давайте представим ваш поток и для каждого шага прикинем сколько времени задача проводит на каждом этапе, а сколько времени на каждом этапе над задачей действительно работают. Разделив сумму второго на сумму первого, команды, как правило, очень удивляются полученным значениям в 10-25%, ведь по их ощущениям эффективность собственной работы никак не ниже 75-80%. Но это же не расчёт, это оценка.
Таким образом, метрика эффективности потока довольно бесполезна, и считать её не нужно. Может, даже и вредно. Грубая оценка — да, отлично. Расчёт, диаграмма, анализ, выводы — нет, не стоит.
Пожалуйста, переубедите меня. Научите считать. Покажите пример. Наверняка я что-то упускаю.