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