Сведения о процессах и шаблонах процессов по умолчанию

  • Статья

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

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

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

Срок Description
Модель обработки Ссылается на модель, используемую для поддержки проектов, созданных для организации или коллекции проектов. Одновременно поддерживается только одна модель процесса для проекта.
Обработка Определяет стандартные блоки системы отслеживания рабочих элементов и поддерживает модель процесса наследования для Azure Boards. Эта модель поддерживает настройку проектов с помощью пользовательского интерфейса WYSIWYG.
Шаблон процесса Определяет стандартные блоки системы отслеживания рабочих элементов и других подсистем, к которые вы обращаетесь через Azure DevOps. Шаблоны процессов используются только с моделями процессов размещенного XML и локального XML-процесса . Вы можете настроить проекты, изменив и импортируя xml-файлы определения шаблона процесса.

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

Совет

С помощью Azure DevOps Server можно выбрать вариант между использованием модели наследуемого процесса или локальной модели XML-процесса. Дополнительные сведения см. в разделе "Выбор модели процесса" для коллекции проектов в разделе "Настройка процесса отслеживания работы". Чтобы получить доступ к последним версиям шаблонов процессов и процессов по умолчанию, выполните следующие действия.

  • Наследуемая модель процесса: откройте страницу "Процессы ". Дополнительные сведения см. в разделе "Управление процессами".
  • Локальная модель xml-процесса:
    • Установите или обновите до последней версии Azure DevOps Server.
    • Скачайте ZIP-файл шаблона с помощью диспетчера шаблонов процессов. Необходимо использовать версию Visual Studio на том же уровне версии, что и Azure DevOps Server. Вы можете установить последнюю версию Visual Studio Community бесплатно.
    • Вы можете получить доступ к последним версиям шаблонов процессов по умолчанию, установленных на сервере Azure DevOps Server, например: %programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033 Описание каждого файла и папки см. в разделе "Обзор файлов шаблонов процесса".

Процессы по умолчанию

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

  • Базовый: является самым легким и находится в выборочной предварительной версии.
  • Scrum: Является следующим самым легким.
  • Agile: поддерживает множество терминов метода Agile.
  • CMMI: обеспечивает большую поддержку формальных процессов и управления изменениями.

Примечание.

Базовый процесс доступен в Azure DevOps Server 2019 с обновлением 1 и более поздними версиями.

Базовая

Выберите "Базовый" , когда ваша команда хочет простейшей модели, которая использует типы рабочих элементов Issue, Task и Epic для отслеживания работы.

Задачи поддерживают отслеживание оставшихся работ.

Базовые типы рабочих элементов

Agile

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

Дополнительные сведения о методологиях Agile см. в разделе "Гибкий альянс".

Задачи поддерживают отслеживание исходной оценки, оставшейся работы и завершенной работы.

Типы гибких рабочих элементов

Scrum

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

Этот процесс поддерживает методологию Scrum, определенную организацией Scrum.

Задачи поддерживают отслеживание оставшихся работ.

Типы рабочих элементов Scrum

CMMI

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

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

Типы рабочих элементов CMMI

Если вам требуется более двух или трех уровней невыполненной работы, добавьте дополнительные сведения на основе используемой модели процесса:

Основные различия между процессами по умолчанию

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

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

Область отслеживания

Базовая

Agile

Scrum

CMMI

Состояния рабочего процесса

  • Необходимо выполнить
  • Выполняется
  • Выполнено
  • Новый
  • Активно
  • "Разрешено"
  • Закрытые
  • Удаленные
  • Новый
  • Утвержденная
  • Зафиксировано
  • Выполнено
  • Удаленные
  • Предложено
  • Активно
  • "Разрешено"
  • Закрытые

Планирование продуктов (см. примечание 1)

  • Проблема
  • Пользовательская история
  • Ошибка (необязательно)
  • Элемент невыполненной работы продукта
  • Ошибка (необязательно)
  • Требование
  • Ошибка (необязательно)

Невыполненные работы портфеля (см. примечание 2)

  • Ситуация
  • Ситуация
  • Функция
  • Ситуация
  • Функция
  • Ситуация
  • Функция

Планирование задач и спринтов (см. примечание 3)

  • Задача
  • Задача
  • Ошибка (необязательно)
  • Задача
  • Ошибка (необязательно)
  • Задача
  • Ошибка (необязательно)

Управление невыполненной работой ошибок (см. примечание 1)

  • Проблема
  • Служба
  • Служба
  • Служба

Управление вопросами и рисками

  • Проблема
  • Проблема
  • Препятствием
  • Проблема
  • Риск
  • Отзыв

Примечания:

  1. Добавьте рабочие элементы из невыполненной работы продукта или доски Kanban. Невыполненная работа продукта показывает одно представление текущей невыполненной работы, которое может быть динамически переупорядочено и сгруппировано. Владельцы продуктов могут быстро определять приоритеты работы и структуры зависимостей и связей. Кроме того, каждая команда может настроить, как они хотят , чтобы ошибки отображались в своих невыполненных работах и досках.
  2. Определите иерархию невыполненных работ портфеля, чтобы понять область работы в нескольких командах и узнать, как эта работа выполняется в более широких инициативах. Каждая команда настраивает, какие невыполненные работы портфеля отображаются для их использования.
  3. Определите задачи из невыполненной работы с спринта и доски задач. С помощью планирования емкости команды могут быстро определить, слишком ли они слишком или недостаточно для спринта.

Состояния рабочего процесса, переходы и причины

Состояния рабочего процесса поддерживают отслеживание состояния работы при переходе New из состояния в состояние Closed или Done состояние. Каждый рабочий процесс состоит из набора состояний, допустимых переходов между состояниями и причин перехода рабочего элемента в выбранное состояние.

Внимание

Для Azure DevOps Services и Azure DevOps Server 2019 рабочий процесс по умолчанию поддерживает любое состояние на любой переход состояния. Настройте эти рабочие процессы, чтобы ограничить некоторые переходы. Дополнительные сведения см. в разделе "Настройка объектов отслеживания работы" для поддержки процессов вашей команды.

Кроме того, просмотрите поддерживаемые переходы рабочих процессов для каждого типа рабочего элемента, установив расширение Marketplace визуализации модели состояния. Это расширение добавляет новый концентратор в Boards с меткой визуализатор состояния. На этой странице выберите тип рабочего элемента и просмотрите модель состояния рабочего процесса.

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

Пользовательская история

Снимок экрана: состояния рабочего процесса

Функция

Снимок экрана: состояния рабочего процесса компонента с помощью гибкого процесса.

Ситуация

Снимок экрана: состояния эпического рабочего процесса с помощью гибкого процесса.

Служба

Снимок экрана: состояния рабочего процесса ошибки с помощью гибкого процесса

Задача

Снимок экрана: состояния рабочего процесса задачи с помощью гибкого процесса

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

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

Состояния рабочих элементов

При изменении состояния рабочего элемента Removedна ( Closedили Done) система отвечает следующим образом:

  • Closed/Done: рабочие элементы в этом состоянии не отображаются на страницах невыполненной работы портфеля и невыполненной работы. Они отображаются на страницах невыполненной работы с спринта, доске Kanban и доске задач. Кроме того, при изменении представления невыполненной работы портфеля на отображение элементов невыполненной работы, например для просмотра элементов невыполненной работы продукта, отображаются рабочие элементы в Closed состоянии и Done состоянии.
  • Removed: рабочие элементы в этом состоянии не отображаются в невыполненной работе или доске.

Проект сохраняет рабочие элементы до тех пор, пока проект активен. Даже если для рабочих элементов Closedзадано значение , Doneили Removedхранилище данных сохраняет запись. Используйте запись для создания запросов или отчетов.

Примечание.

Завершенные или закрытые рабочие элементы не отображаются в невыполненных журналах и досках после их значения "Измененная дата " больше 183 дней (около половины года). Эти элементы по-прежнему можно перечислить с помощью запроса. Если вы хотите, чтобы они отображались в невыполненной работы или доске, вы можете внести незначительные изменения в них, что сбрасывает часы.

Примечание.

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

Если необходимо окончательно удалить рабочие элементы, см. статью "Удалить или удалить рабочие элементы".

Типы рабочих элементов, добавленные во все процессы

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

Снимок экрана: типы рабочих элементов, используемые планами тестирования, диспетчерами тестов Майкрософт, my Work и Feedback.

Ваша команда может создавать и работать с этими типами с помощью соответствующего средства.

Средство Типы рабочих элементов
Microsoft Test Manager Test Plan, , Test SuiteTest Case Shared StepsShared Parameters
Запрос обратной связи Feedback Request, Feedback Response
Моя работа (от команды Обозреватель), проверка кода Code Review Request, Code Review Response

Рабочие элементы из этих определений типов не предназначены для создания вручную и затем добавляются в категорию Hidden Types . Типы рабочих элементов, добавленные в категорию Hidden Types , не отображаются в меню, которые создают новые рабочие элементы.

Типы рабочих элементов, поддерживающие тестовый интерфейс

Типы рабочих элементов, поддерживающие тестовый интерфейс и работа с Диспетчером тестов и веб-порталом, связаны вместе с помощью типов ссылок, показанных на следующем рисунке.

Снимок экрана: типы рабочих элементов управления тестами.

На веб-портале или Microsoft Test Manager просмотрите тестовые случаи для набора тестов и просмотрите наборы тестов, определенные для плана тестирования. Однако эти объекты не подключены друг к другу через типы ссылок. Настройте эти типы рабочих элементов так же, как и другие типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка объектов отслеживания работы" для поддержки процессов вашей команды.

Если изменить рабочий процесс для тестового плана и набора тестов, может потребоваться обновить конфигурацию процесса, как описано здесь. Определения каждого тестового поля см. в разделе "Запрос" на основе полей интеграции сборки и тестирования.