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

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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

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

Примечание

Рекомендации по настройке и настройке проекта и команд для поддержки бизнес-потребностей см. в разделе "Конфигурация и настройка Azure Boards".

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

Совет

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

Совет

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

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

Совет

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

Выбор базового, гибкого, scrum и CMMI-процесса

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

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

Примечание

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

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

Основной

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

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

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


Agile

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

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

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

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


Scrum

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

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

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

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


CMMI

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

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

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


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

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

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

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

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

Основной

Agile

Scrum

CMMI


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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Важно!

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

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

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

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

Состояния рабочего процесса пользовательской истории, гибкий процесс

Компонент

Состояния рабочего процесса компонентов, гибкий процесс

Легенда

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

Bug

Состояния рабочего процесса ошибок, гибкий процесс

Задача

Состояния рабочего процесса задачи, гибкий процесс

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

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

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

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

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

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

Примечание

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

Примечание

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

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

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

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

Типы рабочих элементов, используемые Test Plans, диспетчерами microsoft Test Manager, My Work и Feedback

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

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

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

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

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

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

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

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

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

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