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

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

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

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

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

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

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

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

Кроме того, можно массово добавлять требования с помощью файла cvs.

Внимание

Интеграция Microsoft Project и TFSFieldMapping команда не поддерживаются для:

• Visual Studio 2019 и Azure DevOps Office Integration 2019.
• Azure DevOps Server 2019 и более поздних версий, включая Azure DevOps Services.

Полная поддержка интеграции Microsoft Excel поддерживается и поддерживает массовый импорт и обновление рабочих элементов. К альтернативным вариантам использования Microsoft Project относятся:

• Планы доставки.
• Расширение Marketplace, например проект Подключение или диаграмма GANTT.

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

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

Поле

Использование

---

Description

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

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

Оценка влияния

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

Тип требования (обязательный)

Тип требования для реализации. Можно указать одно из следующих значений:

• Бизнес-цель
• Функция (по умолчанию)
• Функциональные
• Интерфейс
• Операционные
• Качество обслуживания
• Сейф ty
• Сценарий
• Безопасность

Область значений

Область ценности клиента, адресованная эпическому, компоненту, требованию или элементу невыполненной работы. Доступные значения:

• Архитектура: технические службы для реализации бизнес-функций, которые обеспечивают решение
• Бизнес: службы, которые выполняют потребности клиентов или заинтересованных лиц, которые напрямую обеспечивают ценность клиента для поддержки бизнеса (по умолчанию)

Размер

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

Исходная оценка

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

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

Дата начала и дата окончания

Целевые даты начала или завершения работы.

Приоритет (обязательный)

Субъективная оценка требования, связанная с бизнесом. Допустимые значения:

• 1. Продукт не может отправляться без элемента.
• 2. (по умолчанию) Продукт не может отправляться без элемента, но он не должен быть немедленно устранен.
• 3. Реализация элемента является необязательной на основе ресурсов, времени и риска.

Триаж (обязательный)

Указывает тип решения о сортировке, ожидающего рабочего элемента. Используйте это поле, если рабочий элемент находится в предлагаемом состоянии и укажите одно из следующих значений: "Ожидание" (по умолчанию), "Дополнительные сведения", "Полученная информация" и "Тригед".

Заблокировано

Указывает, не удалось ли участнику команды выполнить ход реализации требования или задачи или устранения ошибки, запроса на изменение или риска. Если проблема была открыта для отслеживания проблемы блокировки, можно создать ссылку на проблему. Можно указать данет.

Зафиксировано (обязательно)

Указывает, зафиксировано ли требование в проекте или нет. Можно указать да или нет (по умолчанию).

Интегрированная в

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

Проверка принятия пользователем (требуется)

Состояние теста принятия пользователем для требования. Можно указать одно из следующих значений:

• Пройти
• Не пройден
• Not Ready (по умолчанию)
• Готово
• Пропущено
• Полученные сведения

Если требование находится в активном состоянии, укажите "Готово", когда это требование находится в состоянии "Разрешено".

Экспертов

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

---

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

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

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

Примечание.

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

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

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

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

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

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

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

Полный журнал аудита всех измененных и удаленных комментариев сохраняется на вкладке "Журнал " в форме рабочего элемента.

Добавление реакции на комментарий

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

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

Примечание.

Эта функция доступна начиная с Azure DevOps Server 2022.1.

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

После сохранения комментариев вам не нужно сохранять рабочий элемент.

Примечание.

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

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

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

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

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

Требование	Служба	Задача

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

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

Обновление состояния работы с помощью Kanban или Taskboards

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

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

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

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

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

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

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

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

Назовите задачу и оцените ее работу.

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

Поле

Использование

Тип задачи

Выберите тип задачи для реализации из допустимых значений:

• Исправление действия

• Действие по устранению рисков

• Планово

Дисциплины

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

• Анализ

• Разработка

• Тестирование

• Обучение пользователей

• Взаимодействие с пользователем

Это поле также используется для вычисления емкости по дисциплине. Он назначается type="Activity" в файле ProcessConfiguration. (2)

Дополнительные сведения см. в разделе "Реализация задач разработки".

Исходная оценка

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

Оставшиеся трудоемкие

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

Завершенная работа

Объем работы, затраченной на реализацию задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

Поле или вкладка

Использование

---

Заголовок

Введите описание 255 символов или меньше. Вы всегда можете изменить заголовок позже.

Назначено

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

Штат

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

Причина

Сначала используйте значение по умолчанию. Обновите его при изменении состояния. Каждое состояние связано с причиной по умолчанию.

Область

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

Итерация

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

(Журнал)

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

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

(Ссылки)

Добавьте все типы ссылок, такие как гиперссылки, наборы изменений, исходные файлы и т. д.

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

(Вложения)

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

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

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

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

• Создание проекта
• Добавление рабочих элементов для управления проектом
• Создание невыполненной работы
• Использование доски Kanban
• Планирование спринта

Порядок невыполненной работы

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

Это поле не отображается в форме рабочего элемента.