Управление типами рабочих элементов процесса Scrum и рабочим процессом
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Чтобы спланировать проект программного обеспечения и отслеживать дефекты программного обеспечения с помощью Scrum, команды используют элемент невыполненной работы продукта (PBI) и типы рабочих элементов ошибок (WIT). Чтобы получить представление о портфеле функций, сценариев или пользовательских возможностей, владельцев продуктов и руководителей программ, можно сопоставить PBIs и ошибки с функциями. Когда команды работают в спринтах, они определяют задачи, которые автоматически связываются с PBIs и ошибками.
Примечание.
Если вы не знакомы с процессом Scrum, просмотрите сведения о Sprints, Scrum и управлении проектами.
Тестировщики могут создавать и запускать тестовые случаи и создавать ошибки для отслеживания дефектов кода с помощью веб-портала или Microsoft Test Manager. Препятствия отслеживают проблемы блокировки.
Определение PBIs и ошибок
При определении элемента невыполненной работы продукта сосредоточьтесь на значении, которое клиенты получают и избегают описания того, как ваша команда разрабатывает эту функцию. Владелец продукта может определить приоритет невыполненной работы продукта на основе ценности, усилий и относительной зависимости от других элементов невыполненной работы. По мере развития бизнес-требований это делает невыполненную работу продукта. Как правило, команды указывают сведения только для элементов с наивысшим приоритетом или те элементы, назначенные текущему и следующему спринту.
Вы можете создать PBIs и ошибки на панели быстрого добавления на странице невыполненной работы продукта.
После этого вы можете открыть каждый PBI или ошибку, чтобы предоставить дополнительные сведения и оценить усилия. Кроме того, при приоритете PBIs и ошибок на странице невыполненной работы (которая фиксируется в поле "Приоритет невыполненной работы"), владельцы продуктов могут указать, какие элементы должны быть предоставлены более высокий приоритет.
При определении усилий для PBIs и ошибок можно использовать функцию прогнозирования и диаграммы скорости для оценки будущих спринтов или рабочих усилий. При определении бизнес-ценности владельцы продуктов могут указывать приоритеты отдельно от изменяемого ранжирования стека невыполненных работ.
Используйте следующие поля и поля, используемые в распространенных типах рабочих элементов при завершении формы рабочего элемента. Дополнительные сведения см. в разделе "Управление ошибками".
Поле или вкладка
Использование
Оцените объем работы, необходимой для выполнения PBI, используя любую единицу измерения, которую предпочитает ваша команда, например точки истории или время. Требуется числовое значение.
Гибкие диаграммы скорости и средства прогнозирования ссылались на значения в этом поле. Дополнительные сведения см. в техническом документе оценки.
Укажите число, которое фиксирует относительное значение PBI по сравнению с другими ТСОП. Чем выше число, тем больше значение бизнеса.
Укажите достаточно подробных сведений о том, сколько трудоемких работ требуется для реализации элемента. Сосредоточьтесь на том, кто является функцией, какие пользователи хотят достичь, и почему. Не описывайте, как следует разрабатывать функцию. Предоставьте достаточные сведения, чтобы ваша команда может создавать задачи и тестовые варианты для реализации элемента.
Определите, что означает "Готово", описывая критерии, которые команда должна использовать для проверки того, был ли полностью реализован PBI или исправление ошибок.
Прежде чем начать работу с PBI или ошибкой, опишите критерии принятия клиентом как можно более четко. Беседы между командой и клиентами, чтобы определить критерии принятия, помогают обеспечить общее понимание в команде для удовлетворения ожиданий клиентов. Критерии принятия можно использовать в качестве основы для приемочных тестов, чтобы команда могли более эффективно оценить, был ли элемент удовлетворительно завершен.
Запись комментариев в разделе "Обсуждение"
Используйте раздел "Обсуждение", чтобы добавить и просмотреть комментарии, сделанные о выполняемой работе.
Панель инструментов редактора форматированного текста отображается под областью записи текста. При выборе каждого текстового поля, поддерживающего форматирование текста.
Примечание.
Поле рабочего элемента "Обсуждение" отсутствует. Чтобы запросить рабочие элементы с комментариями, введенными в области обсуждения, вы фильтруете поле журнала. Все содержимое текста, введенного в текстовое поле "Обсуждение", добавляется в поле "Журнал".
Упоминать кого-то, группу, рабочий элемент или запрос на вытягивание
Чтобы открыть меню последних записей, которые вы сделали, чтобы упоминание кого-то, связаться с рабочим элементом или связаться с запросом на вытягивание, выбрать 
или 
ввести @#, или .!
Введите имя или номер и фильтры списка меню, чтобы соответствовать вашей записи. Выберите запись, которую вы хотите добавить. Чтобы перенести группу в обсуждение, введите @ имя группы, например команду или группу безопасности.
Изменение или удаление комментария
Чтобы изменить или удалить любые комментарии к обсуждению, нажмите кнопку 
"Изменить" или выберите 
значок действий, а затем нажмите кнопку "Удалить".
Примечание.
Для редактирования и удаления комментариев требуется azure DevOps Server 2019 с обновлением 1 или более поздней версии.
После обновления комментария нажмите кнопку "Обновить". Чтобы удалить комментарий, убедитесь, что вы хотите удалить его.
Полный журнал аудита всех измененных и удаленных комментариев сохраняется на вкладке "Журнал " в форме рабочего элемента.
Внимание
Для локального сервера Azure DevOps server необходимо настроить SMTP-сервер для участников группы для получения уведомлений.
Добавление реакции на комментарий
Добавьте одну или несколько реакций на комментарий, выбрав значок смайлики в правом верхнем углу любого комментария. Или выберите из значков в нижней части комментария рядом с любыми существующими реакциями. Чтобы удалить реакцию, выберите реакцию в нижней части комментария. На следующем рисунке показан пример опыта добавления реакции и отображения реакций на комментарий.
Сохранение комментария без сохранения рабочего элемента
Примечание.
Эта функция доступна начиная с Azure DevOps Server 2022.1.
Если у вас есть только разрешения на добавление в обсуждение рабочего элемента, это можно сделать, сохранив примечания. Это разрешение контролируется узлами пути области и комментариями к рабочему элементу в этом узле. Дополнительные сведения см. в разделе "Настройка разрешений отслеживания работы", создание дочерних узлов, изменение рабочих элементов в области или пути итерации.
После сохранения комментариев вам не нужно сохранять рабочий элемент.
Отслеживание хода выполнения
По мере выполнения работы вы изменяете поле "Состояние", чтобы обновить состояние. При необходимости можно указать причину. Поля состояния и причины отображаются в форме рабочего элемента в области заголовка.
Состояния рабочего процесса Scrum
При обновлении состояния команды знают, какие элементы являются новыми, выполняемыми или завершенными. Большинство WIT поддерживают переход как вперед, так и назад от каждого состояния рабочего процесса. На этих схемах показаны основные состояния прогрессии и регрессии PBI, ошибки и WIT задач.
| Элемент невыполненной работы | Служба | Задача |
|---|---|---|
|
|
|
PBIs и ошибки соответствуют типичному прогрессу рабочего процесса:
- Владелец продукта создает PBI или тестировщик создает ошибку в новом состоянии с причиной по умолчанию, новый элемент невыполненной работы
- Владелец продукта перемещает элемент в утвержденный после достаточного описания и готовности команды оценить уровень усилий. Большую часть времени элементы, расположенные в верхней части невыполненной работы продукта, находятся в состоянии "Утверждено", а элементы в середине и нижней части находятся в новом состоянии
- Команда обновляет состояние "Зафиксировано", когда они решили зафиксировать работу над ним во время спринта
- Элемент перемещается в состояние "Готово ", когда команда выполнила все связанные задачи, и владелец продукта согласен с тем, что он был реализован в соответствии с критериями принятия.
Обновление состояния с помощью kanban или taskboards
Teams может использовать доску Kanban для обновления состояния PBIS и спринта Taskboard для обновления состояния задач. Перетаскивание элементов в новый столбец состояния обновляет поля "Состояние" и "Причина".
Вы можете настроить доску Kanban, чтобы поддерживать больше плаваловых полос или столбцов. Другие параметры настройки см. в разделе "Настройка взаимодействия с отслеживанием работы".
Сопоставление PBIs с функциями
При управлении набором продуктов или пользовательских возможностей может потребоваться просмотреть область и ход работы в портфеле продуктов. Для этого определите функции и сопоставите PBIS с функциями.
С помощью невыполненных журналов портфеля можно выполнить детализацию из одной невыполненной работы на другую , чтобы просмотреть нужный уровень детализации. Кроме того, при настройке иерархии команд можно использовать невыполненные операции портфеля.
Определение задач
Когда ваша команда управляет своей работой в спринтах, они могут использовать страницу невыполненной работы с спринта, чтобы разбить работу на различные задачи.
Назовите задачу и оцените ее выполнение.
Teams может прогнозирует работу и определяет задачи в начале каждого спринта, и каждый член команды завершает подмножество этих задач. Задачи могут включать разработку, тестирование и другие виды работы. Например, разработчик может определять задачи для реализации PBIS, а тестировщик может определять задачи для записи и выполнения тестовых случаев.
Когда команды оценивают работу с помощью часов или дней, они определяют задачи и поля оставшихся рабочих и действий (необязательно).
Поле или вкладка
Использование
Укажите, сколько часов или дней осталось для выполнения задачи. По мере выполнения работы обновите это поле. Он используется для вычисления диаграмм емкости, диаграммы спринта сгоревшего и отчета Sprint Burndown (Scrum).
Если задача разделена на подзадачи, укажите оставшиеся трудозадачи только для подзадач. Вы можете указать работу в любой единице измерения, выбранной командой.
Выберите тип действия, который эта задача представляет, когда команда оценивает емкость спринта по действиям.
Отслеживание хода выполнения теста
Тестовые PBIs
На веб-портале или диспетчере тестов можно создавать тестовые случаи, которые автоматически связываются с PBI или ошибкой. Кроме того, можно связать PBI или ошибку с тестовый случай на вкладке 
(ссылки).
Тестовый случай содержит множество полей, многие из которых автоматизированы и интегрированы с Диспетчером тестов и процессом сборки. Описание каждого поля см. в разделе "Запрос" на основе полей сборки и тестирования интеграции.
Вкладка "Ссылки" записывает ссылки на все PBIs и ошибки в тестовом случае. Связав PBIs и ошибки для тестирования случаев, команда может отслеживать ход выполнения тестирования каждого элемента.
Отслеживание дефектов кода
Ошибки можно создавать на веб-портале веб-портала, Visual Studio или при тестировании с помощью Test Manager.
Определения общих полей отслеживания рабочих процессов
В большинстве рабочих элементов отображаются следующие поля и вкладки. Каждая вкладка используется для отслеживания определенных сведений, таких как 
журнал, ссылки или
вложения. Эти три вкладки предоставляют журнал изменений, представление связанных рабочих элементов и возможность просмотра и присоединения файлов.
Единственным обязательным полем для всех типов рабочих элементов является Title. При сохранении рабочего элемента система назначает ему уникальный идентификатор. Форма выделяет обязательное поле желтым цветом. Сведения о других полях см. в разделе "Индекс поля рабочего элемента".
Примечание.
Дополнительные поля могут потребоваться в зависимости от настроек, внесенных в процесс и проект.
Поле или вкладка
Использование
Введите описание 255 символов или меньше. Вы всегда можете изменить заголовок позже.
Назначьте рабочий элемент участнику группы, ответственному за выполнение работы.
Когда рабочий элемент создается, состояние по умолчанию соответствует первому состоянию в рабочем процессе. По мере выполнения работы обновите его, чтобы отразить текущее состояние.
Сначала используйте значение по умолчанию. Обновите его при изменении состояния. Каждое состояние связано с причиной по умолчанию.
Выберите путь области, связанный с продуктом или командой, или оставьте пустым, пока не назначено во время собрания планирования. Чтобы изменить раскрывающийся список областей, см. статью "Определение путей к областям" и назначение команде.
Выберите спринт или итерацию, в которой должна быть завершена работа, или оставьте его пустым и назначьте его позже во время собрания планирования. Чтобы изменить раскрывающийся список итерации, см. раздел "Определение путей итерации" (спринтов) и настройка итерации команды.
Просмотрите путь аудита, который система захватывает и захватывает дополнительные сведения.
Каждый раз, когда рабочий элемент обновляется, сведения добавляются в журнал. Журнал включает дату изменения, которые внесли изменения и какие поля были изменены. Вы также можете добавить форматированный текст в поле журнала.
Добавьте все типы ссылок, такие как гиперссылки, наборы изменений, исходные файлы и т. д.
На этой вкладке также перечислены все ссылки, определенные для рабочего элемента.
Предоставление более подробной информации путем добавления файлов в рабочий элемент, таких как потоки электронной почты, документы, изображения, файлы журнала или другие типы файлов.
Настройка типов рабочих элементов
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования".
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования" или настройка локальной модели XML-процессов в зависимости от модели процесса, используемой проектом.
Отслеживание препятствий
Используйте тип рабочего элемента "Препятствия" для отслеживания событий, которые могут блокировать ход выполнения или отправлять PBI. Используйте тип рабочего элемента ошибки исключительно для отслеживания дефектов кода.
Вы можете добавить препятствия из мини-приложения "Новый рабочий элемент", добавленного на панель мониторинга группы, или из меню "Создать " на странице "Запросы ".
Рабочие элементы, добавленные из мини-приложения, автоматически область в область по умолчанию вашей команды и пути итерации. Сведения об изменении контекста команды см. в разделе "Переключение контекста команды".
Порядок невыполненной работы
Поле "Невыполненный приоритет" используется для отслеживания относительного ранжирования PBIs, ошибок, функций или эпических элементов. Однако по умолчанию он не отображается в форме рабочего элемента. Последовательность элементов на странице невыполненной работы определяется в соответствии с местом добавления элементов или перемещения элементов на странице. При перетаскивании элементов фоновый процесс обновляет это поле.
Связанные статьи
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по