Типы рабочих элементов и рабочий процесс процесса CMMI в Azure Boards

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

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

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

С помощью Microsoft Test Manager и веб-портала тестировщики создают и запускают тестовые случаи и определяют ошибки для отслеживания дефектов кода.

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

Определение требований

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

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

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

Запись комментариев в разделе "Обсуждение"

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

Панель инструментов редактора форматированного текста отображается под областью ввода текста при отображении курсора в любом текстовом поле, поддерживающем форматирование текста.

Упоминать кого-то, группу, рабочий элемент или запрос на вытягивание

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

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

Изменение или удаление комментария

Чтобы изменить или удалить любые комментарии к обсуждению, нажмите кнопку "Изменить" или выберите значок действий, а затем нажмите кнопку "Удалить".

После обновления комментария нажмите кнопку "Обновить". Чтобы удалить комментарий, убедитесь, что вы хотите удалить его. Вкладка «Журнал» в форме рабочего элемента сохраняет полный аудиторский след всех измененных и удаленных комментариев.

Отслеживание хода выполнения работы

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

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

На этих схемах показаны основные состояния прогрессии и регрессии для WIT требований, ошибок и задач.

Требование	Ошибка	Задача

Типичный ход выполнения рабочего процесса для требования:

• Владелец продукта создает требование в предлагаемом состоянии с причиной по умолчанию, новым требованием.
• Владелец продукта обновляет состояние "Активный ", когда начинается его реализация.
• Команда обновляет состояние "Разрешено " после завершения разработки кода и прохождения системных тестов.
• Наконец, владелец команды или владелец продукта переводит требование в Закрыто, когда владелец продукта согласен, что оно выполнено в соответствии с критериями приемки и прошло все тесты проверки.

Обновление состояния работы с помощью доски или доски задач

Teams может использовать доску для обновления состояния требований и доски задач спринта для обновления состояния задач. Перетаскивание элементов в новый столбец состояния обновляет поля "Состояние" и "Причина".

Вы можете настроить доску для поддержки более плаваловых полос или столбцов.

Сопоставление требований к функциям

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

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

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

Определение задач

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

Назовите задачу и оцените объем необходимой работы.

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

Отслеживание хода выполнения теста

Требования к тестированию

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

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

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

Отслеживание дефектов кода

Ошибки можно создавать на веб-портале, Visual Studio или при тестировании с помощью Test Manager.

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

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

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

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

Определения общих полей отслеживания рабочих процессов

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

Единственным обязательным полем для всех типов рабочих элементов является Title. При сохранении рабочего элемента система назначает ему уникальный идентификатор. Форма выделяет обязательное поле желтым цветом. Сведения о других полях см. в разделе "Индекс поля рабочего элемента".

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

Связанные статьи

• Создание проекта
• Добавление рабочих элементов для управления проектом
• Создание невыполненной работы
• Управление доступом к определенным функциям
• Сведения о разрешениях и уровнях доступа по умолчанию для Azure Boards

Порядок списка невыполненных задач

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

Это поле не отображается в форме задачи.