Типы рабочих элементов и рабочий процесс процесса CMMI в Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Teams используют типы рабочих элементов (WIT), предоставляемые в MSF для улучшения процесса CMMI 2015 (CMMI), для планирования и отслеживания хода выполнения проектов программного обеспечения. Teams определяют требования к управлению невыполненной работой, а затем с помощью доски отслеживают ход выполнения, обновляя состояние требований.
Чтобы получить представление о портфеле требований, владельцы продуктов могут сопоставить требования с функциями. Когда команды работают в итерации, они определяют задачи, которые автоматически связываются с требованиями.
С помощью 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, такие как диаграмма Project Connect или GANTT
Требования указывают функции и элементы продукта, которые необходимо создать командам. Владельцы продуктов обычно определяют требования ранжирования и стека на странице невыполненной работы продукта. Затем команда определяет размер усилий по доставке наиболее приоритетных элементов.
Используйте приведенные ниже рекомендации и предоставленные поля, используемые в общих типах рабочих элементов при заполнении формы. Дополнительные сведения см. в разделе "Планирование проекта".
Поле
Использование
Укажите достаточно подробных сведений о том, сколько работ потребуется для реализации требования. Сосредоточьтесь на том, кто это требует, какие пользователи хотят достичь, и почему. Не описывайте, как должно быть разработано требование. Предоставьте достаточные сведения, чтобы ваша команда может создавать задачи и тестовые варианты для реализации элемента.
В полях HTML можно добавить форматированный текст и изображения.
Влияние клиента на не реализацию этого требования. Вы можете включить сведения из модели Kano о том, находится ли это требование в сюрпризе, обязательных или очевидных категориях. Эти сведения записываются в поле HTML с форматированным текстом, соответствующем оценке влияния.
Тип требования (обязательный)
Тип требования для реализации. Можно указать одно из следующих значений:
- Бизнес-цель
- Функция (по умолчанию)
- Функциональный
- Интерфейс
- Эксплуатационный
- Качество обслуживания
- Безопасность
- Сценарий
- Безопасность
Область ценности клиента, адресованная эпическому, компоненту, требованию или элементу невыполненной работы. Доступные значения:
- Архитектура: технические службы для реализации бизнес-функций, которые обеспечивают решение
- Бизнес: службы, которые выполняют потребности клиентов или заинтересованных лиц, которые напрямую обеспечивают ценность клиента для поддержки бизнеса (по умолчанию)
Оцените объем работы, необходимый для выполнения требования, используя любую числовую единицу измерения, которую предпочитает ваша команда. Определив размер требований, команды могут использовать гибкие диаграммы скорости и средства прогнозирования для оценки будущих итераций или рабочих усилий. Схема накопительного потока ссылается на значения в этом поле. Дополнительные сведения см. в техническом документе оценки.
Объем предполагаемой работы, необходимой для выполнения задачи. Как правило, это поле не изменяется после назначения.
Вы можете указать работу в часах или в днях. Не существует встроенных единиц времени, связанных с этим полем.
Целевые даты начала или завершения работы.
Приоритет (обязательный)
Субъективная оценка требования, связанная с бизнесом. Допустимые значения:
- 1. Продукт не может отправляться без элемента.
- 2. (по умолчанию) Продукт не может отправляться без элемента, но он не должен быть немедленно устранен.
- 3. Реализация элемента является необязательной на основе ресурсов, времени и риска.
Триаж (обязательный)
Указывает тип решения о сортировке, ожидающего рабочего элемента. Используйте это поле, если рабочий элемент находится в предлагаемом состоянии и укажите одно из следующих значений: "Ожидание" (по умолчанию), "Дополнительные сведения", "Полученная информация" и "Тригед".
Указывает, не удалось ли участнику команды выполнить ход реализации требования или задачи или устранения ошибки, запроса на изменение или риска. Если проблема была открыта для отслеживания проблемы блокировки, можно создать ссылку на проблему. Можно указать да нет.
Зафиксировано (обязательно)
Указывает, зафиксировано ли требование в проекте или нет. Можно указать да или нет (по умолчанию).
Номер сборки продукта, который включает требование, запрос на изменение или исправляет ошибку.
Проверка принятия пользователем (требуется)
Состояние теста принятия пользователем для требования. Можно указать одно из следующих значений:
- Проходить
- Не пройден
- Not Ready (по умолчанию)
- Готово
- Пропущено
- Полученные сведения
Если требование находится в активном состоянии, укажите "Готово", когда это требование находится в состоянии "Разрешено".
Имена участников группы, знакомых с клиентской областью, которая представляет это требование.
Запись комментариев в разделе "Обсуждение"
Используйте раздел "Обсуждение", чтобы добавить и просмотреть комментарии, сделанные о выполняемой работе.
Панель инструментов редактора форматированного текста отображается под областью записи текста, когда курсор помещается в любое текстовое поле, поддерживающее форматирование текста.
Примечание.
Поле рабочего элемента "Обсуждение" не существует. Чтобы запросить рабочие элементы с комментариями из области обсуждения, отфильтруйте поле журнала. Полное содержимое текста, введенного в текстовое поле "Обсуждение", добавляется в поле "Журнал".
Упоминать кого-то, группу, рабочий элемент или запрос на вытягивание
Выберите один из следующих значков, чтобы открыть меню последних записей, в которых вы упомянули кого-то, связанного с рабочим элементом или связанного с запросом на вытягивание. Кроме того, можно открыть то же меню, введя @#или !.
Введите имя или номер, чтобы отфильтровать список меню, чтобы соответствовать вашей записи. Выберите запись, которую нужно добавить. Чтобы перенести группу в обсуждение, введите @ имя группы, например команду или группу безопасности.
Изменение или удаление комментария
Чтобы изменить или удалить любые комментарии к обсуждению, нажмите кнопку 
"Изменить" или выберите 
значок действий, а затем нажмите кнопку "Удалить".
Примечание.
Для редактирования и удаления комментариев требуется azure DevOps Server 2019 с обновлением 1 или более поздней версии.
После обновления комментария нажмите кнопку "Обновить". Чтобы удалить комментарий, убедитесь, что вы хотите удалить его. Полный журнал аудита всех измененных и удаленных комментариев сохраняется на вкладке "Журнал " в форме рабочего элемента.
Внимание
Для локального сервера Azure DevOps server настройте SMTP-сервер для участников группы для получения уведомлений.
Добавление реакции на комментарий
Добавьте одну или несколько реакций на комментарий, выбрав значок смайлики в правом верхнем углу любого комментария. Или выберите из значков в нижней части комментария рядом с любыми существующими реакциями. Чтобы удалить реакцию, выберите реакцию в нижней части комментария. На следующем рисунке показан пример опыта добавления реакции и отображения реакций на комментарий.
Сохранение комментария без сохранения рабочего элемента
Примечание.
Эта функция доступна начиная с Azure DevOps Server 2022.1.
Если у вас есть только разрешения на добавление в обсуждение рабочего элемента, это можно сделать, сохранив примечания. Это разрешение контролируется узлами пути области и комментариями к рабочему элементу в этом узле. Дополнительные сведения см. в разделе "Настройка разрешений отслеживания работы", создание дочерних узлов, изменение рабочих элементов в области или пути итерации.
После сохранения комментариев вам не нужно сохранять рабочий элемент.
Отслеживание хода выполнения работы
По мере выполнения работы вы изменяете поле "Состояние", чтобы обновить состояние. При необходимости можно указать причину. Поля состояния и причины отображаются в форме рабочего элемента в области заголовка.
Состояния рабочего процесса CMMI
На этих схемах показаны основные состояния прогрессии и регрессии для wiT-адресов задач и требований.
| Требование | Ошибка | Задача |
|---|---|---|
 |
 |
 |
Типичный ход выполнения рабочего процесса для требования:
- Владелец продукта создает требование в предлагаемом состоянии с причиной по умолчанию, новым требованием.
- Владелец продукта обновляет состояние "Активный ", когда начинается его реализация.
- Команда обновляет состояние "Разрешено " после завершения разработки кода и прохождения системных тестов.
- Наконец, владелец команды или продукта перемещает требование закрыто , когда владелец продукта согласен с тем, что он был реализован в соответствии с критериями принятия и прошел все тесты проверки.
Обновление состояния работы с помощью доски или доски задач
Teams может использовать доску для обновления состояния требований и доски задач спринта для обновления состояния задач. Перетаскивание элементов в новый столбец состояния обновляет поля "Состояние" и "Причина".
Вы можете настроить доску для поддержки более плаваловых полос или столбцов.
Сопоставление требований к функциям
При управлении набором продуктов или пользовательских возможностей может потребоваться просмотреть область и ход выполнения работы в портфеле продуктов. Вы можете просмотреть область, определив функции и сопоставив требования к функциям.
С помощью невыполненных журналов портфеля можно выполнить детализацию из одной невыполненной работы на другую , чтобы просмотреть нужный уровень детализации. Кроме того, при настройке иерархии команд можно использовать невыполненные операции портфеля.
Рабочий элемент компонента содержит аналогичные поля, предоставляемые для требований, и включает другие поля, как описано в следующей таблице.
Определение задач
Когда ваша команда управляет своей работой в спринтах, они могут использовать страницу невыполненной работы с спринта, чтобы разбить работу на различные задачи.
Назовите задачу и оцените ее работу.
Когда команды оценивают работу, они определяют задачи и оценивают часы или дни выполнения задач. Команды прогнозируют работу и определяют задачи в начале итерации, и каждый член команды выполняет подмножество этих задач. Задачи могут включать разработку, тестирование и другие виды работы. Например, разработчик может определять задачи для реализации требований, а тестировщик может определять задачи для записи и запуска тестовых случаев. Связав задачи с требованиями и ошибками, они видят ход выполнения этих элементов. Дополнительные сведения см. в разделе "Действия итерации".
Поле
Использование
Выберите тип задачи для реализации из допустимых значений:
Исправление действия
Действие по устранению рисков
Планово
Выберите дисциплину, которую эта задача представляет, когда команда оценивает емкость спринта по действиям.
Анализ
Разработка
Тестирование
Обучение пользователей
Взаимодействие с пользователем
Это поле также используется для вычисления емкости по дисциплине. Он назначается type="Activity" в файле ProcessConfiguration. (2)
Дополнительные сведения см. в разделе "Реализация задач разработки".
Объем предполагаемой работы, необходимой для выполнения задачи. Как правило, это поле не изменяется после назначения.
Объем оставшейся работы для выполнения задачи. По мере выполнения работы обновите это поле. Он используется для вычисления диаграмм емкости, диаграммы спринта сгоревшего и отчета Sprint Burndown. Если задача разделена на подзадачи, укажите часы только для подзадач. Вы можете указать работу в любой единице измерения, выбранной командой.
Объем работы, затраченной на реализацию задачи.
Отслеживание хода выполнения теста
Требования к тестированию
На веб-портале или диспетчере тестов можно создавать тестовые случаи, которые автоматически связываются с требованием или ошибкой. Кроме того, можно связать требование с тестовой ситуацией на вкладке 
"Ссылки".
Тестовый случай содержит множество полей, многие из которых автоматизированы и интегрированы с Диспетчером тестов и процессом сборки. Описание каждого поля см. в разделе "Запрос" на основе полей сборки и тестирования интеграции.
На вкладке "Ссылки" перечислены все требования и ошибки в тестовом случае. С помощью связывания команда может отслеживать ход выполнения тестирования каждого элемента и поддерживать сведения, отображаемые в отчете "Обзор требований".
Отслеживание дефектов кода
Ошибки можно создавать на веб-портале веб-портала, Visual Studio или при тестировании с помощью Test Manager.
Отслеживание запросов на изменение, рисков, проблем и заметок, записанных в собраниях проверки
Помимо требований, функций, задач и WIT ошибок, можно отслеживать информацию, рекомендуемую процессом CMMI, используя следующие WITS.
- Запрос на изменение для управления предлагаемыми изменениями любого рабочего продукта, который находится под контролем изменений.
- Проблема для отслеживания события или ситуации, которая может блокировать работу или блокирует работу над продуктом. Проблемы отличаются от рисков в командах , которые определяют проблемы спонтанно, как правило, во время ежедневных собраний команд.
- Риск отслеживать вероятность и степень дисперсии между фактическими и требуемыми результатами. При управлении рисками стратегически свести к минимуму дисперсию между нужным результатом и фактическим результатом.
- Просмотрите , чтобы документировать результаты проверки дизайна или кода. Участники команды могут записывать сведения о том, как дизайн или код соответствует стандартам в областях правильности имен, релевантности кода, расширяемости, сложности кода, алгоритмической сложности и безопасности кода.
Вы можете добавить проблему из мини-приложения "Новый рабочий элемент", добавленного на панель мониторинга группы, или из меню "Создать" на странице "Запросы".
Рабочие элементы, добавляемые из мини-приложения, автоматически определяются областью по умолчанию вашей команды и путями итерации. Сведения об изменении контекста команды см. в разделе "Переключение контекста команды".
Определения общих полей отслеживания рабочих процессов
В большинстве рабочих элементов отображаются следующие поля и вкладки. Каждая вкладка используется для отслеживания определенных сведений, таких как 
журнал, ссылки или
вложения. Эти три вкладки предоставляют журнал изменений, представление связанных рабочих элементов и возможность просмотра и присоединения файлов.
Единственным обязательным полем для всех типов рабочих элементов является Title. При сохранении рабочего элемента система назначает ему уникальный идентификатор. Форма выделяет обязательное поле желтым цветом. Сведения о других полях см. в разделе "Индекс поля рабочего элемента".
Примечание.
Дополнительные поля могут потребоваться в зависимости от настроек, внесенных в процесс и проект.
Поле или вкладка
Использование
Введите описание 255 символов или меньше. Вы всегда можете изменить заголовок позже.
Назначьте рабочий элемент участнику группы, ответственному за выполнение работы.
Когда рабочий элемент создается, состояние по умолчанию соответствует первому состоянию в рабочем процессе. По мере выполнения работы обновите его, чтобы отразить текущее состояние.
Сначала используйте значение по умолчанию. Обновите его при изменении состояния. Каждое состояние связано с причиной по умолчанию.
Выберите путь области, связанный с продуктом или командой, или оставьте пустым, пока не назначено во время собрания планирования. Чтобы изменить раскрывающийся список областей, см. статью "Определение путей к областям" и назначение команде.
Выберите спринт или итерацию, в которой должна быть завершена работа, или оставьте его пустым и назначьте его позже во время собрания планирования. Чтобы изменить раскрывающийся список итерации, см. раздел "Определение путей итерации" (спринтов) и настройка итерации команды.
Просмотрите путь аудита, который система захватывает и захватывает дополнительные сведения.
Каждый раз, когда рабочий элемент обновляется, сведения добавляются в журнал. Журнал включает дату изменения, которые внесли изменения и какие поля были изменены. Вы также можете добавить форматированный текст в поле журнала.
Добавьте все типы ссылок, такие как гиперссылки, наборы изменений, исходные файлы и т. д.
На этой вкладке также перечислены все ссылки, определенные для рабочего элемента.
Предоставление более подробной информации путем добавления файлов в рабочий элемент, таких как потоки электронной почты, документы, изображения, файлы журнала или другие типы файлов.
Настройка типов рабочих элементов
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования".
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования" или настройка локальной модели XML-процессов в зависимости от модели процесса, используемой проектом.
Связанные статьи
- Создание проекта
- Добавление рабочих элементов для управления проектом
- Создание невыполненной работы
- Управление доступом к определенным функциям
- Сведения о разрешениях и уровнях доступа по умолчанию для Azure Boards
Порядок невыполненной работы
Поле Ранжирования стека используется для отслеживания относительного ранжирования требований, функций или эпических элементов. Однако по умолчанию он не отображается в форме рабочего элемента. Последовательность элементов на странице невыполненной работы определяется в соответствии с местом добавления элементов или перемещения элементов на странице. При перетаскивании элементов фоновый процесс обновляет это поле.
Это поле не отображается в форме рабочего элемента.