Гибкий рабочий процесс в Azure Boards

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

При применении гибкого процесса в Azure Boards можно использовать несколько типов рабочих элементов (WIT) для планирования и отслеживания хода выполнения проекта. Доступные WIT включают в себя эпики, фичи, пользовательские истории, таски, проблемы и баги. После определения WIT можно использовать доску для отслеживания хода выполнения, обновив состояние для определенных элементов.

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

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

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

Определение историй пользователей

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

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

Снимок экрана: форма рабочего элемента

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

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

Field

Usage


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

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

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

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

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

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

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

Субъективная оценка относительной неопределенности успешного завершения истории пользователя. Допустимые значения:

  • 1 - Высокий уровень
  • 2 — средний
  • 3 — низкий

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

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

Снимок экрана: раздел

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

Снимок экрана: раздел

Note

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

Упомянуть кого-то, группу, рабочий элемент или pull request

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

Одно и то же меню можно открыть с помощью сочетаний клавиш: упоминание @, хэштег #, и восклицательный знак !.

Снимок экрана: раздел

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

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

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

Снимок экрана: раздел

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

Important

Для локального сервера Azure DevOps server настройте SMTP-сервер для участников группы для получения уведомлений.

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

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

Снимок экрана: раздел

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

Note

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

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

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

Снимок экрана: раздел

Note

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

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

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

Снимок экрана: форма рабочего элемента ошибки, область заголовка с полями состояния и причины.

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

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

Концептуальное изображение состояний рабочего процесса

Концептуальное изображение состояния потока обработки ошибок, Agile.

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

Ниже приведена типичная прогрессия рабочего процесса для истории пользователя:

  1. Владелец продукта создает историю пользователя в новом состоянии с причиной по умолчанию, новой историей пользователя.
  2. Команда обновляет статус истории на "Активный", когда они принимают решение завершить работу во время спринта.
  3. История переходит в решено состояние, когда команда завершает все связанные задачи и модульные тесты истории проходят.
  4. История переходит в закрытое состояние, когда владелец продукта соглашается, что история реализуется в соответствии с критериями принятия и тестами принятия.

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

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

Снимок экрана слежения за прогрессом на доске.

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

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

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

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

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

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

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

Назовите задачу и оцените работу, которая выполняется в разделе "Усилия ":

Снимок экрана: форма рабочего элемента задачи Agile.

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

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

Field

Usage


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

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

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

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

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

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

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

Тестовые истории пользователей

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

Снимок экрана: веб-портал плана тестирования.

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

Снимок экрана: форма тест-кейса.

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

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

Вы можете создавать ошибки на веб-портале, Visual Studio или при тестировании с помощью Диспетчера тестов для отслеживания ошибок кода.

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

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

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

Note

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

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

Usage


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

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

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

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

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

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

Вкладка "История"

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

Вкладка "Ссылки"

Добавьте ссылки для создания соединений с другими рабочими элементами. Поддерживаются такие ссылки, как гиперссылки, наборы изменений, исходные файлы и многое другое. Укажите связь связанного элемента с рабочим элементом, например Parent, Found in Build или Test Result.

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

Отслеживание других проблем

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

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

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

Отслеживание бизнес-ценности

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

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

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

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

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

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