Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Вы используете накопительные диаграммы потока (CFD) для мониторинга потока работы через систему. Две основные метрики для отслеживания, времени цикла и времени выполнения можно извлечь из диаграммы. Чтобы настроить или просмотреть диаграммы CFD, см. Настройка накопительной диаграммы потоков.
Кроме того, можно добавить контрольные диаграммы времени выполнения и времени цикла на панели управления.
Примеры диаграмм и основных метрик
Непрерывный поток CFD предоставляет диаграмму, которая наиболее благоприятна командам, которые следуют бережливому процессу.
Однако многие команды начали сочетать бережливые практики с методологией Scrum или другими методологиями, что означает, что они применяют бережливые подходы в рамках итерации или спринта. В этой ситуации схема имеет немного другой вид и предоставляет два дополнительных и очень ценных фрагментов информации, как показано на следующей диаграмме.
Непрерывный поток
Фиксированный период CFD здесь показан для завершенного спринта.
Верхняя строка представляет объем работ, установленный для спринта. И, поскольку работа должна быть завершена последним днем спринта, наклон закрытого состояния указывает, находится ли команда на пути к завершению спринта. Самый простой способ представить это — как диаграмму выгорания.
Данные всегда отображаются так, что первый шаг процесса находится в верхнем левом углу, а последний шаг – в нижнем правом углу.
Фиксированный период CFD для завершенного спринта
Метрики диаграммы
Диаграммы CFD отображают количество рабочих элементов, сгруппированных по состоянию или столбцу с течением времени. Две основные метрики для отслеживания, времени цикла и времени выполнения можно извлечь из диаграммы.
Метрика
Определение
Время цикла1
Измеряет время, необходимое для перемещения по одному процессу или состоянию рабочего процесса. Вычисление выполняется с начала одного процесса до начала следующего процесса.
Срок выполнения заказа1
Для процесса непрерывного потока: измеряет время выполнения запроса (например, добавление предлагаемой истории пользователя), пока этот запрос не будет завершен (закрыт).
Для процесса спринта или фиксированного периода: измеряет время от начала работы с запросом до завершения работы (т. е. время от состояния 'Активный' до состояния 'Закрытый').
Работа в процессе выполнения
Измеряет объем выполняемой работы или количество рабочих элементов, над которыми активно работают.
Область применения
Представляет объем работы, зафиксированной в течение заданного периода времени. Применяется только к процессам фиксированного периода.
1 Виджет CFD (аналитика) и встроенная диаграмма CFD (хранилище данных отслеживания работы) не предоставляют дискретные значения по времени выполнения и времени цикла. Однако мини-приложения для времени выполнения и времени цикла предоставляют эти числа.
Существует четко определенная корреляция между временем выполнения/циклом выполнения и незавершенной работой (WIP). Чем больше WIP, тем больше длительность цикла, а это также приводит к более длительному времени выполнения. Противоположность также верна — чем меньше WIP, тем короче цикл и время выполнения. Когда команда разработчиков фокусируется на меньшем количестве элементов, они сокращают цикл и время выполнения. Эта корреляция является ключевой причиной, по которой можно и следует задать ограничения на ход выполнения работы на доске.
Количество рабочих элементов указывает общий объем работы в течение заданного дня. В периоде CFD изменение счетчика указывает на изменение области охвата за данный период. В непрерывном потоке CFD указывает общий объем работы в очереди и завершенной за заданный день.
Разделение работы на определенные столбцы доски обеспечивает видимость того, на каком этапе находятся задачи. Это представление предоставляет аналитические данные о том, где работа идет гладко, где есть препятствия и где работа вовсе не выполняется. Тем не менее, трудно понять табличное представление данных, однако визуальная диаграмма CFD предоставляет доказательства того, что что-то происходит определенным образом.
Определение проблем, выполнение соответствующих действий
CFD отвечает на несколько конкретных вопросов и на основе ответа удается предпринять меры для настройки процесса, чтобы работа проходила через систему. Рассмотрим каждый из этих вопросов здесь.
Будет ли команда выполнять работу вовремя?
Этот вопрос применяется только к фиксированным периодам CFD. Вы получаете понимание, глядя на кривую (или прогрессию) работы в последнем столбце доски.
В этом сценарии может потребоваться уменьшить объем работы в итерации, если ясно, что работа в устойчивом темпе не выполняется достаточно быстро. Это может указывать на то, что работа была недооценена и должна быть учтена в следующем планировании спринтов.
Однако могут быть и другие причины, которые можно определить, просмотрев другие данные на диаграмме.
Как продвигается работа?
Работает ли команда в стабильном темпе? Один из способов проверить — это посмотреть на расстояние между разными столбцами на диаграмме. Равномерно ли они расположены друг от друга от начала до конца? Кажется ли, что столбец держится на одном уровне в течение нескольких дней? Или кажется, оно "выпирает"?
Мура, термин бережливого производства для обозначения плоских линий и выпуклостей, означает неравномерность и указывает на форму отходов (муда) в системе. Любая неравномерность в системе приведет к появлению дефектов в CFD.
Мониторинг CFD для обнаружения ровных линий и выпуклостей поддерживает ключевую роль в процессе управления проектами в соответствии с Теорией ограничений. Защита наиболее медленной части системы называется процессом «барабан-буфер-веревка» и является частью планирования работы.
Две проблемы отображаются визуально как плоские линии и как выпуклости.
Плоские линии появляются, когда команда не обновляет свою работу с регулярной периодичностью. Доска обеспечивает самый быстрый способ перехода работы с одного столбца на другой.
Неструктурированные линии также могут отображаться, когда работа в одном или нескольких процессах занимает больше времени, чем запланировано. Плоские линии отображаются во многих частях системы, потому что если только одна часть системы или две части системы имеют проблемы, то вы увидите выпуклость.
Плоские линии
Заторы возникают, когда работа накапливается в одной части системы и не проходит через процесс.
Например, выпуклость может возникать, когда тестирование занимает длительный период времени, тогда как разработка занимает более короткий период времени, что приводит к накоплению работы в состоянии разработки (выпуклость указывает на наличие проблемы на следующем шаге, а не обязательно там, где возникла выпуклость).
Выпуклости
Как устранить проблемы с потоком?
Вы можете решить проблему нехватки своевременных обновлений с помощью следующих способов:
- Ежедневные собрания 'стоя'.
- Другие регулярные собрания.
- Планирование ежедневного командного напоминания по электронной почте.
Системные проблемы с плоской линией указывают на более сложную проблему, хотя такие проблемы редки. Горизонтальные линии указывают, что работа по всей системе остановлена. Основные причины могут быть:
- Блоки на уровне процесса.
- Процессы занимают много времени.
- Переход на другие возможности, которые не отображаются на доске.
Один из примеров системного застоя может возникать при использовании особенностей CFD. Работа с функциями может занять гораздо больше времени, чем работа над историями пользователей, так как функции состоят из нескольких историй. В этих ситуациях ожидается либо наклон (как и в приведенном выше примере), либо проблема хорошо известна и уже вызывается командой в качестве проблемы. Если это известная проблема, решение проблемы выходит за рамки этой статьи.
Команды могут упреждающе устранять проблемы, которые проявляются как выпуклости на CFD. В зависимости от того, где происходит выпуклость, исправление может отличаться. Например, предположим, что выпуклость возникает в процессе разработки. Увеличение может быть связано с тем, что выполнение тестов требует больше времени, чем написание кода. Тестировщики также могут находить большое количество ошибок. При регулярном возвращении работы разработчикам они наследуют растущий список активных задач.
Два потенциально простых способа решения этой проблемы: 1) Перенаправить разработчиков с процесса разработки на процесс тестирования до устранения узкого места или 2) изменить порядок работы так, чтобы работа, которую можно выполнить быстро, чередовалась с работой, требующей больше времени на выполнение. Ищите простые решения для устранения выпуклости.
Примечание.
Так как многие различные сценарии могут возникать, что приводит к неравномерной работе, важно выполнить фактический анализ проблемы. CFD сообщит вам, что существует проблема и где она приблизительно находится, но вы должны исследовать, чтобы выявить первопричины. Приведенные здесь рекомендации указывают на рекомендуемые действия, которые решают конкретные проблемы, но которые могут не применяться к вашей ситуации.
Изменилась ли область?
Изменения пределов применяются только к CFD с фиксированным сроком. Верхняя строка диаграммы указывает область работы. Спринт начинается с заранее загруженной работы на первый день. Изменения в верхней строке указывают, что работа была добавлена или удалена.
Один из сценариев, когда невозможно отслеживать изменения области с помощью CFD, возникает, если в тот же день добавляется и удаляется одинаковое количество рабочих элементов. Линия будет продолжать оставаться плоской. Сравните несколько диаграмм друг с другом. Отслеживайте конкретные проблемы. Используйте Просмотр/настройка диаграммы сгорания спринта для отслеживания изменений объёма работы.
Слишком много незавершённой работы?
Вы можете легко отслеживать превышение ограничений WIP с доски. Вы также можете отслеживать его из CFD.
Большое количество незавершенной работы обычно отображается как вертикальная выпуклость. Чем дольше имеется большой объем WIP, тем больше выпуклость расширяется и становится овалом. Это признак того, что WIP отрицательно влияет на цикл и время выполнения.
Вот хорошее правило для незавершенных работ. На каждом члена команды в любой момент времени должно быть в процессе не более двух задач. Основная причина сравнения двух элементов с более строгими ограничениями заключается в том, что реальность часто вмешивается в любой процесс разработки программного обеспечения.
Иногда требуется время для получения информации от заинтересованных лиц или требуется больше времени для получения необходимого программного обеспечения. Существует любое количество причин, по которым может быть остановлена работа. Наличие второго рабочего элемента для перехода дает некоторую свободу действий. Если оба элемента блокируются, пришло время вызвать красный флаг, чтобы получить что-то разблокированное, а не просто переключиться на еще один элемент. Как только выполняется большое количество элементов, пользователь, работающий над этими элементами, будет иметь трудности с переключением контекста. Скорее всего, они забудут, что они делают, и могут возникнуть ошибки.
Время выполнения заказа и время цикла
На схеме ниже показано, как время выполнения отличается от времени цикла. Время выполнения вычисляется из создания рабочего элемента до ввода состояния "Завершено". Время цикла вычисляется с момента первого перехода в состояние "Выполняется" или "Разрешено" до перехода в состояние "Завершено".
Иллюстрация времени выполнения и времени цикла
Если рабочий элемент входит в состояние "Завершено", а затем активируется повторно, все дополнительное время, которое оно проводит в состоянии "Предложено", "В разработке" или "Разрешено", будет способствовать времени выполнения или времени цикла, когда оно снова входит в категорию состояния "Завершено".
Если ваша команда использует доску, вам нужно будет понять, как ваши столбцы соотносятся с состояниями рабочего процесса. Дополнительные сведения о настройке доски см. в разделе "Добавление столбцов".
Дополнительные сведения о том, как система использует категории состояний — предлагаемые, выполняемые, разрешенные и завершенные— см. в разделе состояния рабочего процесса и категории состояний.
Планирование, используя оценку времени доставки на основе времени выполнения заказа или цикла.
Для оценки времени доставки можно использовать среднее время выполнения или цикла и стандартные отклонения.
При создании рабочего элемента можно использовать среднее время выполнения команды, чтобы оценить, когда ваша команда завершит этот рабочий элемент. Стандартное отклонение вашей команды указывает на изменчивость оценки. Аналогичным образом можно использовать время цикла и его стандартное отклонение для оценки завершения рабочего элемента после начала работы.
На следующей диаграмме среднее время цикла составляет восемь дней. Стандартное отклонение составляет +/- шесть дней. Используя эти данные, мы можем оценить, что команда завершит будущие истории пользователей около 2-14 дней после начала работы. Чем уже стандартное отклонение, тем более прогнозируемы ваши оценки.
Пример виджета "Время цикла"
Определение проблем с процессом
Просмотрите контрольную диаграмму вашей команды на предмет аномалий. Аномалии часто указывают на проблему основного процесса. Например, слишком долго ожидать завершения проверок PR или небыстрое устранение внешних зависимостей.
Как видно на следующей диаграмме, на которой показаны несколько аномальных значений, на устранение нескольких дефектов потребовалось больше времени, чем в среднем у команды. Изучение того, почему эти ошибки заняли больше времени, могут помочь выявить проблемы с процессом. Устранение проблем с процессом может помочь уменьшить стандартное отклонение вашей команды и улучшить прогнозируемость вашей команды.
Пример виджета "Время цикла", показывающего несколько аномалий
Вы также можете узнать, как изменения процесса влияют на время выполнения и циклов. Например, 15 мая команда предприняла согласованные усилия, чтобы ограничить WIP и устранить устаревшие ошибки. Вы можете увидеть, что стандартное отклонение сужается после этой даты, показывая улучшенную прогнозируемость.