Поделиться через

Шаблоны процессов и процессов по умолчанию

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

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

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

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

Типы процессов по умолчанию : Basic, Agile, Capability Maturity Model Integration (CMMI) и Scrum. Объекты отслеживания работы в шаблонах процессов и процессов по умолчанию одинаковы. Они приведены в этой статье.

Tip

С помощью 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: обеспечивает большую поддержку формальных процессов и управления изменениями.

Basic

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

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

На схеме показаны базовые типы рабочих элементов в иерархии.

Agile

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

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

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

На схеме показаны типы рабочих элементов Agile в иерархии.

Scrum

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

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

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

На схеме показаны типы рабочих элементов Scrum в иерархии.

CMMI

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

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

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

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

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

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

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

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

Basic

Agile

Scrum

CMMI

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

  • Сделать
  • Doing
  • Done
  • New
  • Active
  • Resolved
  • Closed
  • Removed
  • New
  • Approved
  • Committed
  • Done
  • Removed
  • Proposed
  • Active
  • Resolved
  • Closed

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

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

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

  • Epic
  • Epic
  • Feature
  • Epic
  • Feature
  • Epic
  • Feature

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

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

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

  • Issue
  • Bug
  • Bug
  • Bug

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

  • Issue
  • Issue
  • Impediment
  • Issue
  • Risk
  • Review

Notes:

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

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

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

Important

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

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

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

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

История пользователя

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

Feature

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

Epic

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

Bug

Схема, на которой показаны состояния рабочего процесса ошибки с помощью гибкого процесса.

Task

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

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

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

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

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

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

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

Note

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

Note

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

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

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

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

Схема, которая показывает типы рабочих элементов, используемые планами тестирования, менеджерами тестирования Microsoft, My Work и Feedback.

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

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

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

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

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

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

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

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

Связанный контент

  • Last updated on