Управление требованиями
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
В этой статье вы узнаете о ключевых понятиях и задачах, связанных с управлением требованиями к проекту с помощью средств и функций Agile в Azure DevOps.
Совет
Управление требованиями — это непрерывный процесс на протяжении жизненного цикла проекта, охватывающий процессы документирования, анализа, приоритетирования, отслеживания и совместной работы с заинтересованными лицами для согласования работы. Единственное требование соответствует возможности, которая должна соответствовать результату проекта — продукту, службе, архитектуре, производительности.
Определение требований
Использование рабочих элементов для отслеживания требований. Каждый рабочий элемент имеет тип, который зависит от выбранного процесса. Можно также создать пользовательский тип рабочего элемента.
Примечание.
Требования указывают ожидания пользователей для программного продукта. В Azure Boards требования определяются рабочими элементами, которые отображаются в невыполненной работе продукта. В зависимости от процесса, выбранного для проекта, требования соответствуют типам рабочих элементов "История пользователя" (Agile), элемент невыполненной работы продукта (Scrum), "Проблема" (базовый) или "Требование" (CMMI). Они также относятся к категории "Требования", которая управляет типами рабочих элементов, которые отображаются в невыполненной работе продукта.
Типы рабочих элементов
Рабочие элементы позволяют записывать различные сведения и рабочие процессы. Каждый рабочий элемент имеет тип, который зависит от выбранного процесса. Эти типы рабочих элементов по умолчанию можно использовать для требований и дефектов:
- Гибкая: история пользователя и ошибка
- Базовый: проблема и ошибка
- Scrum: Элемент невыполненной работы продукта и ошибка
- CMMI: требование и ошибка
Вы можете настроить каждый процесс для проекта Azure DevOps. Вы также можете решить, как отслеживать ошибки для каждой команды.
Типы рабочих элементов по умолчанию
На следующем рисунке показана иерархия для рабочего элемента невыполненной работы процесса Agile:
- Истории пользователей и задачи используются для отслеживания работы.
- Ошибки отслеживают дефекты кода.
- Эпические и функциональные возможности используются для группирования работы в более крупных сценариях.
Каждая команда может настроить управление рабочими элементами ошибки на том же уровне, что и "История пользователя" или "Рабочие элементы задачи". Используйте параметр "Работа с ошибками". Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе "Гибкий процесс".
Настройка типов рабочих элементов
Пользовательские типы рабочих элементов можно использовать следующим образом:
- Добавление настраиваемых полей и состояний рабочего процесса
- Добавление настраиваемых правил для поддержки бизнес-процессов
- Добавление пользовательских невыполненных журналов портфеля и настройка невыполненных работ и досок
- Добавление пользовательских элементов управления в формы рабочих элементов для получения расширенных функциональных возможностей
Добавление рабочих элементов в невыполненную работу продукта или доску
Зафиксировать требования путем добавления заголовка в невыполненную работу продукта и добавления сведений позже.
Запись требований к невыполненной работы продукта
Поля рабочих элементов
Каждый рабочий элемент поддерживает отслеживание данных, содержащихся в полях рабочих элементов. Кроме того, он фиксирует изменения в виде обновлений в поле журнала и примечаниях, сделанных в разделе "Обсуждение ". На следующем рисунке показан пример формы рабочего элемента для типа рабочего элемента "История пользователя".
Используйте рабочие элементы для поддержки следующих задач:
- Добавление сведений, обновление состояния, назначение участникам группы, связывание рабочих элементов и присоединение файлов
- Назначение работы в папку timebox или спринт
- Быстрое заполнение полей рабочего элемента с помощью шаблонов рабочих элементов
- Участие в потоке обсуждения с запросами
- Определите приоритеты рабочих и трех рабочих элементов.
Другие функции, поддерживающие сквозную трассировку, — это разделы разработки и развертывания . Эти разделы поддерживают следующие задачи и аналитические сведения:
- Создание новой ветви или запроса на вытягивание из рабочего элемента
- Завершение запроса на вытягивание
- Выполнение слияния скваша
- Создание ветви для нескольких рабочих элементов
- Связывание рабочего элемента с существующими объектами разработки и сборки
- Просмотр этапов выпуска, связанных с рабочим элементом в форме рабочего элемента в режиме реального времени
- Просмотр состояния выпусков в этих рабочих элементах, связанных с фиксациями в конвейерах сборки и выпуска
Требования к импорту и обновлению с помощью Excel
Вы также можете использовать файл .csv или электронную таблицу Excel для импорта и обновления требований. Эти средства позволяют работать с неструктурированным списком или деревом рабочих элементов. Например, вы можете определить дерево эпических, функций и пользовательских историй в Excel, а затем импортировать их в Azure DevOps, как показано на следующем рисунке.
Требования к импорту из Excel
Функциональные и нефункциональные требования
Рабочие элементы помогают отслеживать все необходимые вам или вашей команде действия. Для функциональных и нефункциональных требований можно использовать один и тот же тип рабочего элемента. Функциональные требования описывают то, что должен делать ваш продукт или служба. Нефункциональные требования описывают работу продукта или службы.
Теги, поле "Бизнес-значение" или настраиваемое поле можно использовать для классификации ваших требований.
Поддержка спецификаций требований
Некоторые требования требуют дополнительных сведений, чем то, что можно поместить в рабочий элемент. Azure DevOps можно использовать для хранения требований и управления ими в репозитории Azure Repos. Кроме того, вы можете использовать вики-сайт проекта для хранения спецификаций в одном месте.
Вы можете связать или присоединить спецификации к вашим требованиям.
Анализ и приоритет требований
Определите приоритеты и уточните невыполненную работу, чтобы убедиться, что ваши требования четки и четко определены. Эти средства Azure Boards можно использовать для выполнения следующих задач:
Невыполненная работа продукта: перетащите рабочие элементы, чтобы изменить их по приоритету и изменить несколько рабочих элементов одновременно, чтобы изменить назначения или обновить поля. Результаты запросов, режим трижа: просмотрите список рабочих элементов и их форм, чтобы быстро обновить их и добавить сведения.
Приоритет невыполненной работы функций
Группирование и упорядочение требований
Сгруппируйте требования по функциям или бизнес-целям с помощью Azure Boards. Вы можете использовать типы рабочих элементов портфеля, невыполненные работы портфеля и доски, а также средство сопоставления для связывания ваших требований с более высоким уровнем рабочего элемента.
Теги рабочих элементов также можно использовать для группировки требований разными способами.
Эпические, функции и невыполненные работы с портфелем
Используйте ссылки на родительский дочерний элемент, чтобы создать иерархию требований, функций и эпических представлений. Это полезно для организаций с несколькими командами, которые хотят узнать, как их работа способствует достижению общих целей и использованию средств планирования портфеля.
С помощью иерархии можно управлять набором функций, над которыми работают разные команды. Вы также можете просмотреть сводку оценок, хода выполнения и т. д. в невыполненной работе продукта.
Группировать истории пользователей в разделе "Функции" с помощью сопоставления
Использование тегов для группирования рабочих элементов
Теги рабочих элементов — это метки, которые участники команды могут добавлять в рабочие элементы. Вы можете отфильтровать невыполненные журналы и доски по этим тегам, чтобы просмотреть только рабочие элементы, соответствующие им. Теги также можно использовать в запросах. Например, можно просмотреть только карточки с веб-тегом на доске, отфильтровав его с помощью веб-тега , как показано на следующем рисунке.
Фильтрация невыполненных журналов и досок на основе тегов
Реализация Kanban или Scrum
Kanban и Scrum — это два основных метода Гибкой разработки, поддерживаемые Azure Boards. Вы также можете использовать гибридный подход, например Scrumban, который объединяет элементы обоих методов.
Реализация методологии канбан
Используйте доску Kanban для визуализации рабочих элементов в невыполненной работе продукта или портфеля. На доске показаны рабочие элементы, принадлежащие вашей команде, в зависимости от выбранной области и пути итерации.
Вы можете настроить доску в соответствии с рекомендациями Kanban. Например, можно определить столбцы и пловцы, задать ограничения WIP и указать определение готового. Рабочий элемент можно перетащить в другой столбец, чтобы обновить его состояние по мере перемещения по этапам рабочего процесса.
Пример доски
Реализация методологии Scrum
Используйте невыполненную работу спринта и панель задач, чтобы просмотреть рабочие элементы, которые ваша команда планировала для определенного спринта. Рабочие элементы можно назначить спринту, перетаскивая их из невыполненной работы. Затем их можно просмотреть в отдельном невыполненной записи спринта.
Пример невыполненной работы с спринтом
Используйте следующие методики Scrum для планирования и отслеживания работы.
- Выбор спринта для ваших требований
- Разделение требований на задачи
- Задайте, сколько работы каждый участник команды может выполнять в спринте
- Настройка работы в соответствии с емкостью спринта
- Предоставление общего доступа к плану спринта другим пользователям
- Фильтрация, обновление и изменение состояния задач
- Мониторинг хода выполнения спринта с помощью диаграммы сгоревшего
Диаграмма очистки спринта
На диаграмме Спринта сгоревшего экрана показано, как выполняется спринт, обновляя состояние работы каждый день, как показано на следующем рисунке.
Пример диаграммы очистки Спринта
Управление зависимостями
В Microsoft Project вы управляете задачами, которые зависят от завершения других задач, связывая их. Чтобы управлять зависимостями в Azure Boards, можно связать рабочие элементы с помощью типа ссылки "Предшественник и преемник". После связывания рабочих элементов можно просмотреть связи с помощью расширения Marketplace визуализации рабочих элементов. На следующем рисунке показаны связи между несколькими рабочими элементами.
Чтобы просмотреть полное изображение, щелкните изображение, чтобы развернуть его. 
Щелкните значок закрытия, чтобы закрыть.
Минимальный жизнеспособный продукт и управление критическими путями
Azure Boards не имеет встроенного способа показать критический путь, так как методы Agile предпочитают минимальный жизнеспособный продукт (MVP) для управления критическими путями (CPM). С помощью MVP вы найдете самый короткий и зависимый путь путем ранжирования эпиков, функций, историй и задач по важности.
Выполнение планирования вехи
Вы можете использовать скорость команды и прогнозирование для планирования, когда вы можете доставить свою работу.
Скорость команды
Работа с спринтами помогает понять скорость вашей команды. Скорость показывает, сколько работ ваша команда может завершить в спринте на основе числа или размера завершенных рабочих элементов.
Пример диаграммы скорости команды
Требования к прогнозу
Используйте средство прогнозирования для оценки точек истории, усилий или размера для каждого требования.
Вы также можете задать скорость команды на основе ваших оценок. Например, если вы говорите, что ваша команда может сделать 12 точек истории на спринт, средство прогнозирования показывает, какие требования и функции можно завершить в следующих шести спринтах. Средство планирования можно использовать для назначения требований прогнозируемым спринтам.
Пример прогноза невыполненных требований
[
]
Используйте расширение Marketplace для интеграции требований планирования с инструментами Microsoft Project.
Маркеры вехи
Маркеры вехи не используются в отслеживании работы с Azure Boards, за исключением планов доставки. Планы доставки предоставляют представление календаря и позволяют определить маркер вехи.
Чтобы пометить рабочий элемент как веху, можно использовать один или несколько следующих параметров:
- Предварительно или добавьте слово Веха в заголовок рабочего элемента
- Добавление тега рабочего элемента с меткой вехи
- Добавление настраиваемого поля с меткой вехи и заполнение его списком вехи выбора
- Связывание рабочих элементов с помощью типа предшественника или преемника или связанного ссылки с вехой рабочего элемента
- Назначьте рабочий элемент вехи спринту, в котором он предназначен для завершения.
Назначение требований к почтовым ящикам
Вы можете быстро назначить рабочие элементы спринту с помощью перетаскивания из невыполненной работы продукта на спринт, указанный в области планирования.
Пример назначения требований к спринтам
Мониторинг и отчет о ходе выполнения
Чтобы просмотреть ход выполнения и конечные результаты, можно использовать следующие средства:
- Доска функций: отображает состояние каждой функции и ее задач
- Невыполненная работа функций: отображает столбцы свертки для функций и их дочерних рабочих элементов
- Планы доставки. Предоставляет временное представление функций и их зависимостей в разных командах
Доска компонентов
Вы также можете использовать доску функций для отслеживания хода выполнения и обеспечения непрерывной доставки ценности. На следующем рисунке показан пример настраиваемой доски компонентов. Он добавил столбцы для различных этапов разработки функций, таких как необходимость получения дополнительных сведений, спецификации Complete, In Progress и Customer Rollout. Эти столбцы отражают естественный поток признаков от предложения к производству.
Пример доски функций с настраиваемыми столбцами
Чтобы просмотреть полное изображение, щелкните изображение, чтобы развернуть его. Щелкните значок закрытия, чтобы закрыть.
Свертка
Невыполненная работа функций обеспечивает быстрый и визуальный способ мониторинга хода выполнения. Вы можете добавить столбец индикатора выполнения свертки, чтобы увидеть процент завершения рабочих элементов каждой функции. На следующем рисунке показано, как столбец показывает ход выполнения различных функций.
Пример невыполненной работы с требованиями, показывающий свертки хода выполнения
Планы доставки и несколько конечных результатов команды
Если вы хотите просмотреть функции, предоставляемые несколькими командами по временной шкале, можно настроить план доставки. План доставки — это интерактивная доска, показывающая представление календаря историй или функций, которые разные команды планируют доставить.
Пример плана доставки с несколькими командами
Получение уведомлений об изменениях
Azure DevOps предоставляет надежную систему оповещений, где участники проекта могут настраивать оповещения для себя, команды или проекта. При изменении рабочих элементов, проверок кода, файлов системы управления версиями и сборок можно получать Уведомления по электронной почте.