Гибкий рабочий процесс в Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
При использовании гибкого процесса в Azure Boards следующие типы рабочих элементов (WIT) помогают команде планировать и отслеживать ход выполнения проектов: эпические, функции, истории пользователей, задачи, проблемы и ошибки. После определения WIT можно использовать доску для отслеживания хода выполнения, обновив состояние этих элементов.
Чтобы получить представление о портфеле функций, сценариев или пользовательских возможностей, владельцев продуктов и руководителей программ сопоставляют пользовательские истории с функциями. Когда команда работает в спринтах, они определяют задачи , которые автоматически связываются с историями пользователей. Если вы не знакомы с процессом Agile, просмотрите раздел " План" и отслеживайте работу с Agile , чтобы приступить к работе.
На веб-портале или Microsoft Test Manager тестировщики могут создавать и запускать тестовые случаи с ошибками и проблемами, которые используются для отслеживания дефектов кода и блокировки проблем.
Определение историй пользователей
Владельцы продуктов обычно определяют и ранговые истории пользователей стека, описывающие работу, связанную с разработкой приложений, требований и элементов. Затем команда оценивает усилия и работу по доставке наиболее приоритетных элементов.
Создайте истории пользователей на панели быстрого добавления на странице невыполненной работы продукта. На этой странице можно также перетаскивать элементы, чтобы изменить порядок элементов или сопоставить их с функциями.
Вы можете открыть каждую историю пользователя для получения дополнительных сведений и оценки точек истории. Определите точки истории, чтобы ваша команда может использовать функцию прогнозирования и диаграммы скорости для оценки будущих спринтов или рабочих усилий. При приоритете пользовательских историй на странице невыполненной работы (которая записана в поле Stack Rank), владельцы продуктов могут указать, какие элементы должны иметь более высокий приоритет.
Используйте инструкции в следующей таблице и общие поля, используемые для типов рабочих элементов при завершении формы.
Поле или вкладка
Использование
Для историй пользователей предоставьте достаточно подробных сведений о том, сколько работы требуется для реализации истории. Сосредоточьтесь на том, кто является функцией, какие пользователи хотят достичь, и почему. Не описывайте, как следует разрабатывать функцию. Предоставьте достаточные сведения, чтобы ваша команда может создавать задачи и тестовые варианты для реализации элемента.
Предоставьте критерии, которые должны быть выполнены до закрытия ошибки или истории пользователя. Прежде чем начать работу, опишите критерии принятия клиентом как можно более четко. Беседы между командой и клиентами, чтобы определить критерии принятия, помогут вашей команде понять ожидания ваших клиентов. Критерии принятия можно использовать в качестве основы для более эффективного оценки того, является ли элемент удовлетворительно завершенным.
Область ценности клиента, адресованная эпическому, компоненту, требованию или элементу невыполненной работы. Доступные значения:
- Архитектура: технические службы для реализации бизнес-функций, которые обеспечивают решение
- Бизнес: службы, которые выполняют потребности клиентов или заинтересованных лиц, которые напрямую обеспечивают ценность клиента для поддержки бизнеса (по умолчанию)
Оцените объем работы, необходимой для завершения истории пользователя, используя любую числовую единицу измерения, которую предпочитает ваша команда.
Гибкие диаграммы скорости и средства прогнозирования ссылались на значения в этом поле. Дополнительные сведения см. в техническом документе оценки.
Субъективная оценка истории пользователя, функции или требования, связанные с бизнесом. Допустимые значения:
- 1. Продукт не может отправляться без функции.
- 2. Продукт не может отправляться без функции, но он не должен быть решен немедленно.
- 3. Реализация функции является необязательной на основе ресурсов, времени и риска.
Субъективная оценка относительной неопределенности вокруг успешного завершения истории пользователя. Допустимые значения:
- 1 - Высокий
- 2 — средний
- 3 — низкий
Запись комментариев в разделе "Обсуждение"
Используйте раздел "Обсуждение", чтобы добавить и просмотреть комментарии, сделанные о выполняемой работе.
Панель инструментов редактора форматированного текста отображается под областью записи текста, когда курсор помещается в любое текстовое поле, поддерживающее форматирование текста.
Примечание.
Поле рабочего элемента "Обсуждение" не существует. Чтобы запросить рабочие элементы с комментариями из области обсуждения, отфильтруйте поле журнала. Полное содержимое текста, введенного в текстовое поле "Обсуждение", добавляется в поле "Журнал".
Упоминать кого-то, группу, рабочий элемент или запрос на вытягивание
Выберите один из следующих значков, чтобы открыть меню последних записей, в которых вы упомянули кого-то, связанного с рабочим элементом или связанного с запросом на вытягивание. Кроме того, можно открыть то же меню, введя @#или !.
Введите имя или номер, чтобы отфильтровать список меню, чтобы соответствовать вашей записи. Выберите запись, которую нужно добавить. Чтобы перенести группу в обсуждение, введите @ имя группы, например команду или группу безопасности.
Изменение или удаление комментария
Чтобы изменить или удалить любые комментарии к обсуждению, нажмите кнопку 
"Изменить" или выберите 
значок действий, а затем нажмите кнопку "Удалить".
Примечание.
Для редактирования и удаления комментариев требуется azure DevOps Server 2019 с обновлением 1 или более поздней версии.
После обновления комментария нажмите кнопку "Обновить". Чтобы удалить комментарий, убедитесь, что вы хотите удалить его. Полный журнал аудита всех измененных и удаленных комментариев сохраняется на вкладке "Журнал " в форме рабочего элемента.
Внимание
Для локального сервера Azure DevOps server настройте SMTP-сервер для участников группы для получения уведомлений.
Добавление реакции на комментарий
Добавьте одну или несколько реакций на комментарий, выбрав значок смайлики в правом верхнем углу любого комментария. Или выберите из значков в нижней части комментария рядом с любыми существующими реакциями. Чтобы удалить реакцию, выберите реакцию в нижней части комментария. На следующем рисунке показан пример опыта добавления реакции и отображения реакций на комментарий.
Сохранение комментария без сохранения рабочего элемента
Примечание.
Эта функция доступна начиная с Azure DevOps Server 2022.1.
Если у вас есть только разрешения на добавление в обсуждение рабочего элемента, это можно сделать, сохранив примечания. Это разрешение контролируется узлами пути области и комментариями к рабочему элементу в этом узле. Дополнительные сведения см. в разделе "Настройка разрешений отслеживания работы", создание дочерних узлов, изменение рабочих элементов в области или пути итерации.
После сохранения комментариев вам не нужно сохранять рабочий элемент.
Отслеживание хода выполнения
По мере выполнения работы вы изменяете поле "Состояние", чтобы обновить состояние. При необходимости можно указать причину. Поля состояния и причины отображаются в форме рабочего элемента в области заголовка.
Состояния гибкого рабочего процесса
При обновлении рабочего процесса команды знают, какие элементы являются новыми, выполняемыми или завершенными. Большинство WIT поддерживают переход как вперед, так и назад от каждого состояния рабочего процесса. На этих схемах показаны основные состояния прогрессии и регрессии пользовательской истории, ошибки и WIT задач.
| Пользовательская история | Ошибка | Задача |
|---|---|---|
|
|
|
Ниже приведен типичный прогресс рабочего процесса для истории пользователя:
- Владелец продукта создает историю пользователя в новом состоянии с причиной по умолчанию, новой историей пользователя.
- Команда обновляет состояние "Активный ", когда они решили завершить работу во время спринта.
- История пользователя перемещается в "Разрешено ", когда команда выполнила все связанные задачи и модульные тесты для передачи истории.
- История пользователя перемещается в закрытое состояние, когда владелец продукта согласен с тем, что история была реализована в соответствии с критериями принятия и тестами принятия.
Обновление состояния с помощью доски или доски задач
Teams может использовать доску для обновления состояния требований и доски задач для обновления состояния задач. Перетаскивание элементов в новый столбец состояния обновляет поля "Состояние" и "Причина".
Вы можете настроить доску для поддержки дополнительных пловцов или столбцов. Дополнительные сведения см. в разделе "Настройка процесса отслеживания работы".
Сопоставление пользовательских историй с функциями
При управлении набором продуктов или пользовательских возможностей может потребоваться просмотреть область и ход выполнения работы в портфеле продуктов. Вы можете просмотреть область и ход выполнения работы, определив функции и сопоставив истории пользователей с функциями.
С помощью невыполненных журналов портфеля можно выполнить детализацию из одной невыполненной работы на другую , чтобы просмотреть нужный уровень детализации. Кроме того, при настройке иерархии команд воспользуйтесь невыполненной работой в нескольких командах.
Определение задач
Когда ваша команда управляет своей работой в спринтах, они могут использовать страницу невыполненной работы с спринта, чтобы разбить работу на различные задачи.
Назовите задачу и оцените ее выполнение.
При использовании гибкого процесса команды прогнозируют работу и определяют задачи в начале каждого спринта. Затем каждый член группы выполняет подмножество этих задач. Задачи могут включать разработку, тестирование и другие виды работы. Например, разработчик определяет задачи для реализации пользовательских историй, а тестировщик определяет задачи для записи и запуска тестовых случаев.
Когда команды оценивают работу с помощью часов или дней, они определяют задачи и поля оставшихся рабочих и действий (необязательно).
Поле или вкладка
Использование
Объем предполагаемой работы, необходимой для выполнения задачи. Как правило, это поле не изменяется после назначения. Вы можете указать работу в часах или в днях. Не существует встроенных единиц времени, связанных с этим полем.
Объем оставшейся работы для выполнения задачи. По мере выполнения работы обновите это поле. Это поле используется для вычисления диаграмм емкости, диаграммы спринта сгорания и следующих отчетов SQL Server: "Берндаун" и "Скорость записи", "Оставшиеся трудозадачения" и "Состояние" для всех итераций. Если задача разделена на подзадачи, укажите часы только для подзадач. Вы можете указать работу в любой единице измерения, выбранной командой.
Объем работы, затраченной на реализацию задачи.
Выберите тип действия, который эта задача представляет, когда команда оценивает емкость спринта по действиям.
Номер сборки продукта, который включает код или исправляет ошибку.
Отслеживание хода выполнения теста
Отслеживайте ход тестирования с помощью историй пользователей и дефектов кода.
Тестовые истории пользователей
На веб-портале или в Диспетчере тестов можно создавать тестовые случаи, которые автоматически связываются с историей пользователя или ошибкой. Кроме того, вы можете связать историю пользователя с тестовый случай на вкладке 
"Ссылки".
Тестовый случай содержит несколько полей, многие из которых автоматизированы и интегрированы с Диспетчером тестов и процессом сборки. Описание каждого поля см. в разделе "Запрос" на основе полей сборки и тестирования интеграции.
На вкладке (ссылки) записываются ссылки на истории пользователей и ошибки в тестовом случае. Связав истории пользователей и ошибки для тестирования случаев, команда может отслеживать ход выполнения тестирования каждого элемента. Определив эти ссылки, вы поддерживаете сведения, отображаемые в отчете "Обзор историй ".
Отслеживание дефектов кода
Вы можете создавать ошибки на веб-портале, Visual Studio или при тестировании с помощью Test Manager.
Определения общих полей отслеживания рабочих процессов
В большинстве рабочих элементов отображаются следующие поля и вкладки. Каждая вкладка используется для отслеживания определенных сведений, таких как 
журнал, ссылки или
вложения. Эти три вкладки предоставляют журнал изменений, представление связанных рабочих элементов и возможность просмотра и присоединения файлов.
Единственным обязательным полем для всех типов рабочих элементов является Title. При сохранении рабочего элемента система назначает ему уникальный идентификатор. Форма выделяет обязательное поле желтым цветом. Сведения о других полях см. в разделе "Индекс поля рабочего элемента".
Примечание.
Дополнительные поля могут потребоваться в зависимости от настроек, внесенных в процесс и проект.
Поле или вкладка
Использование
Введите описание 255 символов или меньше. Вы всегда можете изменить заголовок позже.
Назначьте рабочий элемент участнику группы, ответственному за выполнение работы.
Когда рабочий элемент создается, состояние по умолчанию соответствует первому состоянию в рабочем процессе. По мере выполнения работы обновите его, чтобы отразить текущее состояние.
Сначала используйте значение по умолчанию. Обновите его при изменении состояния. Каждое состояние связано с причиной по умолчанию.
Выберите путь области, связанный с продуктом или командой, или оставьте пустым, пока не назначено во время собрания планирования. Чтобы изменить раскрывающийся список областей, см. статью "Определение путей к областям" и назначение команде.
Выберите спринт или итерацию, в которой должна быть завершена работа, или оставьте его пустым и назначьте его позже во время собрания планирования. Чтобы изменить раскрывающийся список итерации, см. раздел "Определение путей итерации" (спринтов) и настройка итерации команды.
Просмотрите путь аудита, который система захватывает и захватывает дополнительные сведения.
Каждый раз, когда рабочий элемент обновляется, сведения добавляются в журнал. Журнал включает дату изменения, которые внесли изменения и какие поля были изменены. Вы также можете добавить форматированный текст в поле журнала.
Добавьте все типы ссылок, такие как гиперссылки, наборы изменений, исходные файлы и т. д.
На этой вкладке также перечислены все ссылки, определенные для рабочего элемента.
Предоставление более подробной информации путем добавления файлов в рабочий элемент, таких как потоки электронной почты, документы, изображения, файлы журнала или другие типы файлов.
Настройка типов рабочих элементов
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования".
Для большинства типов рабочих элементов можно добавлять поля, изменять рабочий процесс, добавлять настраиваемые правила и добавлять настраиваемые страницы в форму рабочего элемента. Можно также добавить настраиваемые типы рабочих элементов. Дополнительные сведения см. в разделе "Настройка процесса наследования" или настройка локальной модели XML-процессов в зависимости от модели процесса, используемой проектом.
Связанные статьи
- Создание проекта
- Добавление рабочих элементов для управления проектом
- Создание невыполненной работы
- Управление доступом к определенным функциям
- Сведения о разрешениях и уровнях доступа по умолчанию для Azure Boards
Отслеживание проблем
Проблемы используются для отслеживания событий, которые могут блокировать ход выполнения или доставку истории пользователя. С другой стороны, ошибки используются для отслеживания дефектов кода. Вы можете добавить проблему из мини-приложения "Новый рабочий элемент", добавленного на панель мониторинга группы, или из меню "Создать" на странице "Запросы".
Рабочие элементы, добавляемые из мини-приложения, автоматически определяются областью по умолчанию вашей команды и путями итерации. Сведения об изменении контекста команды см. в разделе "Переключение контекста команды".
Отслеживание бизнес-ценности
Поле "Приоритет" можно использовать для отличия значения различных историй. Кроме того, вы можете добавить настраиваемое поле в WIT пользовательской истории, которая отслеживает относительное значение историй. Дополнительные сведения см. в статье "Настройка поля для процесса".
Порядок невыполненной работы
Поле Stack Rank используется для отслеживания относительного ранжирования историй пользователей, однако по умолчанию он не отображается в форме рабочего элемента. Последовательность элементов на странице невыполненной работы определяется в соответствии с местом добавления элементов или перемещения элементов на странице. При перетаскивании элементов фоновый процесс обновляет это поле.