Руководство по совокупному потоку, времени выполнения и циклу

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Для наблюдения за потоком работы через систему используется накопительная схема потоков (CFS). Две основные метрики для отслеживания, времени цикла и времени выполнения можно извлечь из диаграммы. Сведения о настройке или просмотре диаграммы CF см. в статье "Настройка накопительной блок-диаграммы".

Кроме того, можно добавить диаграммы управления временем и циклом на панели мониторинга.

Примеры диаграмм и основных метрик

Непрерывный поток CF предоставляет диаграмму, которая наиболее благоприячена командам, которые следуют за бережливым процессом.

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

Непрерывный поток

Фиксированный период, показанный здесь, предназначен для завершенного спринта.

Верхняя строка представляет область набор для спринта. И, поскольку работа должна быть завершена последним днем спринта, наклон закрытого состояния указывает, находится ли команда на пути к завершению спринта. Самый простой способ подумать об этом представлении — это диаграмма сжигания.

Данные всегда отображаются с первым шагом процесса в виде верхнего левого и последнего шага процесса в правом нижнем углу.

Фиксированный период ВРЕМЕНИ ДЛЯ завершенного спринта

Метрики диаграммы

Диаграммы CF отображают количество рабочих элементов, сгруппированных по столбцу state/Kanban с течением времени. Две основные метрики для отслеживания, времени цикла и времени выполнения можно извлечь из диаграммы.

---

Метрика

Определение

---

Время^{цикла 1}

Измеряет время, необходимое для перемещения по одному процессу или состоянию рабочего процесса. Вычисление выполняется с начала одного процесса до начала следующего процесса.

Время^{выполнения 1}

Для процесса непрерывного потока: измеряет время выполнения запроса (например, добавление предлагаемой истории пользователя), пока этот запрос не будет завершен (закрыт).

Для процесса спринта или фиксированного периода: измеряет время от начала работы с запросом до завершения работы (т. е. время от активного до закрытого).

Работа в процессе выполнения

Измеряет объем работы или количество рабочих элементов, которые активно работают.

Область применения

Представляет объем работы, зафиксированной в течение заданного периода времени. Применяется только к процессам фиксированного периода.

---

¹ Мини-приложение CF (аналитика) и встроенная диаграмма CF (хранилище данных отслеживания работы) не предоставляют дискретные числа по времени и циклу. Однако мини-приложения времени выполнения и времени цикла предоставляют эти числа.

Существует четко определенная корреляция между временем и циклом свинца и временем выполнения работы (WIP). Чем больше WIP, тем больше времени цикла, что также приводит к более длительному времени свинца. Противоположность также является верной — меньше WIP, чем короче цикл и время свинца. Когда команда разработчиков фокусируется на меньшем количестве элементов, они сокращают цикл и время выполнения. Эта корреляция является ключевой причиной, по которой можно и следует задать ограничения на ход выполнения работы на доске Kanban.

Количество рабочих элементов указывает общий объем работы в течение заданного дня. В фиксированном периоде ЧИСЛО ИЗМЕНЕНИЙ в этом счетчике указывает на область изменения в течение заданного периода. В непрерывном потоке CF указывает общий объем работы в очереди и завершен в течение заданного дня.

Разложение работы на определенные столбцы канбан-доски предоставляет представление о том, где выполняется работа. Это представление предоставляет аналитические сведения о том, где работа движется плавно, где есть блоки и где не выполняется никаких работ вообще. Тем не менее, трудно расшифровать табличное представление данных, однако визуальная диаграмма CF предоставляет доказательства того, что что-то происходит в определенном порядке.

Определение проблем, выполнение соответствующих действий

CfS ответит на несколько конкретных вопросов и на основе ответа, можно предпринять действия, чтобы настроить процесс для перемещения по системе. Рассмотрим каждый из этих вопросов здесь.

Будет ли команда выполнять работу вовремя?

Этот вопрос применяется только к фиксированным периодам CFD. Вы получите понимание, глядя на кривую (или прогрессию) работы в последнем столбце канбан-доски.

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

Однако могут быть и другие причины, которые можно определить, просмотрев другие данные на диаграмме.

Как выполняется процесс работы?

Работает ли команда в стабильном темпе? Один из способов определить интервал между различными столбцами на диаграмме. Они похожи или одинаковые расстояния друг от друга от начала до конца? Представляется ли столбец неструктурированным в течение нескольких дней? Или, кажется, "выпуклость"?

Мура, наклонный термин для плоских линий и выпуклости, означает неравномерность и указывает на форму отходов (Муда) в системе. Любая неравномерность в системе приведет к возникновению выпуклости в CFS.

Мониторинг CF для плоских линий и выпуклости поддерживает ключевую часть процесса управления проектами ограничений. Защита самой медленной области системы называется процессом «барабан-буфер-веревка» и является частью планирования работы.

Две проблемы отображаются визуально как плоские линии и как выпуклые.

Плоские линии появляются, когда команда не обновляет свою работу с регулярной периодичностью. Доска Kanban обеспечивает самый быстрый способ перехода работы с одного столбца на другой.
Неструктурированные линии также могут отображаться, когда работа в одном или нескольких процессах занимает больше времени, чем запланировано. Плоские линии отображаются во многих частях системы, потому что если только одна часть системы или две части системы имеют проблемы, то вы увидите выпуклость.

Плоские линии

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

Выпуклости

Как устранить проблемы с потоком?

Вы можете решить проблему нехватки своевременных обновлений с помощью следующих способов:

• Ежедневные стенды.
• Другие регулярные собрания.
• Планирование ежедневной электронной почты напоминания команды.

Системные проблемы с плоской линией указывают на более сложную проблему, хотя такие проблемы редки. Неструктурированные линии указывают, что работа в системе остановлена. Основные причины могут быть:

• Блоки на уровне процесса.
• Процессы занимает много времени.
• Переход на другие возможности, которые не записываются на борту.

Один из примеров системной плоской линии может возникать с функциями CF. Работа с функциями может занять гораздо больше времени, чем работа над историями пользователей, так как функции состоят из нескольких историй. В этих ситуациях ожидается либо наклон (как и в приведенном выше примере), либо проблема хорошо известна и уже вызывается командой в качестве проблемы. Если это известная проблема, решение проблемы выходит за пределы область этой статьи.

Teams может упреждающим образом устранять проблемы, которые отображаются как выпуклые в формате CF. В зависимости от того, где происходит выпуклость, исправление может отличаться. Например, предположим, что выпуклость возникает в процессе разработки. Выпуклость может происходить, так как выполнение тестов занимает гораздо больше времени, чем написание кода. Тестировщики также могут находить большое количество ошибок. При постоянном переходе работы на разработчиков разработчики разработчики наследуют растущий список активных работ.

Два потенциально простых способа решения этой проблемы: 1) Смена разработчиков из процесса разработки в процесс тестирования до тех пор, пока выпуклость не будет устранена или 2) измените порядок работы таким образом, чтобы работа, которая может быть выполнена быстро, пересекается с работой, которая занимает больше времени для выполнения. Ищите простые решения для устранения выпуклости.

Примечание.

Так как многие различные сценарии могут возникать, что приводит к неравномерной работе, важно выполнить фактический анализ проблемы. CF будет сказать вам, что существует проблема и приблизительно там, где это, но вы должны исследовать, чтобы добраться до первопричин. Приведенные здесь рекомендации указывают на рекомендуемые действия, которые решают конкретные проблемы, но которые могут не применяться к вашей ситуации.

Изменились ли область?

Изменения области применяются только к фиксированным периодам CFD. Верхняя строка диаграммы указывает область работы. Спринт предварительно загружается с работой, чтобы сделать в первый день. Изменения в верхней строке указывают, что работа была добавлена или удалена.

Один из сценариев, в котором невозможно отслеживать область изменения с помощью CFS, возникает при добавлении того же количества рабочих элементов, что и удаленный в тот же день. Линия будет продолжать оставаться плоской. Сравните несколько диаграмм друг с другом. Отслеживайте конкретные проблемы. Используйте режим просмотра и настройки спринта для отслеживания изменений область.

Слишком много WIP?

Вы можете легко отслеживать превышение ограничений WIP с доски Kanban. Вы также можете отслеживать его из CFS.

Большое количество WIP обычно отображается как вертикальная выпуклость. Чем дольше есть большой объем WIP, тем больше выпуклость будет расширяться, чтобы стать овалом. Это признак того, что WIP отрицательно влияет на цикл и время свинца.

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

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

Время свинца и время цикла

На схеме ниже показано, как время выполнения отличается от времени цикла. Время выполнения вычисляется из создания рабочего элемента до ввода состояния "Завершено". Время цикла вычисляется при первом вводе категории состояния "Выполняется" или "Разрешено" для ввода категории состояния "Завершено".

Иллюстрация времени выполнения и времени цикла

Если рабочий элемент входит в состояние "Завершено", а затем активируется повторно, все дополнительное время, которое оно проводит в предлагаемом, в состоянии "Ход выполнения" или "Разрешено" будет способствовать его времени свинца или цикла при вводе категории состояния "Завершено" во второй раз.

Если ваша команда использует доску Kanban, вы хотите понять, как столбцы Kanban сопоставляют с состояниями рабочего процесса. Дополнительные сведения о настройке доски Kanban см. в разделе "Добавление столбцов".

Дополнительные сведения о том, как система использует категории состояний — предлагаемые, выполняемые, разрешенные и завершенные— см. в разделе состояния рабочего процесса и категории состояний.

Планирование с помощью оценки времени доставки на основе времени свинца или цикла

Для оценки времени доставки можно использовать среднее время свинца или цикла и стандартные отклонения.

При создании рабочего элемента можно использовать среднее время выполнения команды, чтобы оценить, когда ваша команда завершит этот рабочий элемент. Стандартное отклонение вашей команды указывает на изменчивость оценки. Аналогичным образом можно использовать время цикла и его стандартное отклонение для оценки завершения рабочего элемента после начала работы.

На следующей диаграмме среднее время цикла составляет восемь дней. Стандартное отклонение составляет +/- шесть дней. Используя эти данные, мы можем оценить, что команда завершит будущие истории пользователей около 2-14 дней после начала работы. Чем более узкое стандартное отклонение, тем более прогнозируемо вашей оценки.

Пример мини-приложения "Время цикла"

Определение проблем с процессом

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

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

Пример мини-приложения "Время цикла", показывающее несколько выскользов

Вы также можете узнать, как изменения процесса влияют на время свинца и цикла. Например, 15 мая команда предприняла согласованные усилия, чтобы ограничить WIP и устранить устаревшие ошибки. Вы можете увидеть, что стандартное отклонение сужается после этой даты, показывая улучшенную прогнозируемость.

Следующие шаги

Настройка накопительных блок-диаграмм или настройка временной диаграммы времени выполнения или цикла