выберите поток процесса или шаблон процесса Azure DevOps Server для работы в Azure Boards или Azure DevOps

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013

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

  • модель процесса относится к модели, используемой для поддержки проектов, созданных для организации (Azure DevOps Services) или коллекции проектов (Azure DevOps Server). Для организации или коллекции одновременно поддерживается только одна модель процессов. Сравнение трех моделей процессов — наследования, локального XML и размещенного XML — предоставляется в области Настройка отслеживания работы.
  • Процесс определяет стандартные блоки системы отслеживания рабочих элементов и поддерживает модель процесса наследования для Azure Boards. Эта модель поддерживает настройку проектов с помощью пользовательского интерфейса WYSIWYG.
  • Шаблон процесса определяет стандартные блоки системы отслеживания рабочих элементов и другие подсистемы, доступ к которым осуществляется с помощью Azure DevOps. Шаблоны процессов используются только с размещенными и локальными моделями XML-процессов. Настройка проектов осуществляется путем изменения и импорта XML-файлов определений шаблонов процессов.

Примечание

Рекомендации по настройке и настройке проекта и команд для поддержки бизнес-потребностей см. в статье Настройка и настройка Azure Boards.

Дополнительные сведения о создании проекта с помощью выбранного процесса см. в разделе Создание проекта. Дополнительные сведения о моделях процессов см. в разделе Настройка процесса отслеживания работы.

Совет

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

Совет

Чтобы получить доступ к последним версиям шаблонов процессов по умолчанию:

Объекты отслеживания работы, содержащиеся в процессах и шаблонах процессов по умолчанию — Basic, Agile, CMMI и Scrum, являются одинаковыми и обобщены ниже. базовый процесс доступен в Azure DevOps Server 2019,1 и более поздних версиях. Для простоты они называются "процессом".

Совет

Сведения о просмотре унаследованных моделей процессов и управлении ими см. в разделе Управление процессами.

Выберите базовый, гибкий процесс, Scrum и CMMI.

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

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

Примечание

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

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

Примечание

ситуаций поддерживаются в Azure Boards и Azure DevOps. Каждая команда может выбрать активные уровни невыполненной работы, как описано в разделе Выбор уровней навигации невыполненной работы для вашей команды.

Основной

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

Примечание

в настоящее время в выборочной предварительной версии для новых пользователей только Azure Boards.

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

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

Agile

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

Дополнительные сведения о методологиях Agile можно получить в Agile Alliance.

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

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

Координатор

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

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

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

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

CMMI

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

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

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

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

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

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

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

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

Основной

Agile

Координатор

CMMI

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

  • Необходимые действия:
  • Выполнение
  • Готово
  • Оператор new
  • Активен
  • "Разрешено"
  • Закрытое
  • Удалено
  • Оператор new
  • Approved
  • Фиксация
  • Готово
  • Удалено
  • Предложено
  • Активен
  • "Разрешено"
  • Закрытое

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

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

Невыполненные работы портфеля (2)

  • Легенда
  • Легенда
  • Компонент
  • Легенда
  • Компонент
  • Легенда
  • Компонент

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

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

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

  • Проблема
  • Bug
  • Bug
  • Bug

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

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

Примечание

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

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

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

Важно!

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

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

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

История, проблемы, иерархия задач

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

История, вопрос, Рабочий процесс задачи

Рабочий процесс базового процесса

Примечание

базовый процесс доступен при создании нового проекта на основе Azure DevOps Services или Azure DevOps Server 2019,1. Для предыдущих развертываний в локальной среде выберите Agile, Scrum или CMMI Process.

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

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

Состояния Удаленный, Закрытый и Завершенный.

Когда изменяет состояние рабочего элемента на Удаленное, Закрытое или Завершенное, система реагирует следующим образом:

  • Закрыто или Готово: рабочие элементы в этом состоянии не отображаются на страницах невыполненной работы портфеля и невыполненной работы. Однако они отображаются на страницах невыполненной работы спринта, на доске Канбан и taskboard. Кроме того, при изменении представления невыполненной работы портфеля на отображение элементов невыполненной работы, например, для просмотра функций элементов невыполненной работы по продукту, отображаются рабочие элементы в состоянии закрыто и готово.
  • Удалено. рабочие элементы в этом состоянии не отображаются в невыполненной работе или на доске.

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

Примечание

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

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

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

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

типы рабочих элементов, используемые Test Plans, диспетчеры тестов (майкрософт), моя работа и обратная связь

Команды создают следующие типы рабочих элементов с помощью соответствующего средства:

  • План тестирования, набор тестов, общие шаги тестового случая и общие параметры: Microsoft Test Manager.
  • Запрос отзыва и ответ на отзыв: Запрос отзыва.
  • Запрос на проверку кода и отклик на проверку кода: "Моя работа" (из командного обозревателя) и Запрос на проверку кода.

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

Примечание

если вы обновили проект с Azure DevOps 2013 или более ранней версии до более поздней версии, может потребоваться добавить wit, которые не существовали в более ранних версиях. Дополнительные сведения см. в разделе Настройка компонентов после обновления.

В указанную версию программного обеспечения добавлены следующие WIT:

  • Общие параметры, добавленные с помощью операций разработки Azure 2013,2
  • план тестирования и набор тестов добавлены с Azure DevOps 2013,3

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

WIT, которые поддерживают тестовую среду и работают с Test Manager и веб-порталом, связаны друг с другом с помощью типов ссылок, показанных на следующем рисунке.

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

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

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

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

дополнительные вопросы см. на странице поддержки Azure DevOps.