Поделиться через


Управление типами рабочих элементов процесса Scrum и рабочим процессом

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

Чтобы спланировать проект программного обеспечения и отслеживать дефекты программного обеспечения с помощью Scrum, команды используют элемент невыполненной работы продукта (PBI) и типы рабочих элементов ошибок (WIT). Чтобы получить представление о портфеле функций, сценариев или пользовательских возможностей, владельцев продуктов и руководителей программ, можно сопоставить PBIs и ошибки с функциями. Когда команды работают в спринтах, они определяют задачи, которые автоматически связываются с PBIs и ошибками.

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

Примечание.

Если вы не знакомы с процессом 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 задач.

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

PBIs и ошибки соответствуют типичному прогрессу рабочего процесса:

  • Владелец продукта создает PBI или тестировщик создает ошибку в новом состоянии с причиной по умолчанию, новый элемент невыполненной работы
  • Владелец продукта перемещает элемент в утвержденный после достаточного описания и готовности команды оценить уровень усилий. Большую часть времени элементы, расположенные в верхней части невыполненной работы продукта, находятся в состоянии "Утверждено", а элементы в середине и нижней части находятся в новом состоянии
  • Команда обновляет состояние "Зафиксировано", когда они решили зафиксировать работу над ним во время спринта
  • Элемент перемещается в состояние "Готово ", когда команда выполнила все связанные задачи, и владелец продукта согласен с тем, что он был реализован в соответствии с критериями принятия.

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

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

Снимок экрана: отслеживание хода выполнения на доске.

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

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

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

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

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

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

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

Назовите задачу и оцените ее выполнение.

Снимок экрана: процесс Scrum, форма рабочего элемента задачи.

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

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

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

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

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

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

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

Тестовые PBIs

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

Снимок экрана: веб-портал, выберите набор тестов и добавьте тестовый случай.

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

Снимок экрана: форма рабочего элемента тестового случая Scrum.

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

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

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

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

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

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

Примечание.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отслеживание препятствий

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

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

Снимок экрана: добавление рабочего элемента из мини-приложения

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

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

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