Настройка и настройка Azure Boards



Только задачи

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

Требования с задачами, зависимыми от дочерних элементов

Поддержка методов Scrum
Рекомендуется для команд, которые следуют за методами Scrum и хотят отслеживать время, связанное с работой.

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

Только требования, например пользовательские истории (Agile), проблемы (Basic), элементы невыполненной работы по продукту (Scrum), требования (CMMI)

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

Требования, сгруппированные по типам рабочих элементов портфеля, например ситуаций и Features

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

Параметры настройки и настройки

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

Настройка или Настройка

Стандартные средства

Аналитика

Средства планирования портфеля

  • Boards > все инструменты
  • Все средства в журнале ожидания >
  • >Все средства спринтов
  • Диаграмма накопительных потоков
  • Скорость
  • Тренд выработки
  • Планы выполнения
  • Временная шкала компонента
  • Epic Roadmap
  • Планы портфеля (бета-версия)
  • Dependency Tracker
  • Планирование спринта невыполненной работы >
  • Спринты невыполненной работы > спринта
  • Производительность спринта спринтов >
  • Спринты > taskboard
  • Скорость
  • Тренд выработки
  • Планы выполнения
  • Временная шкала компонента
  • Epic Roadmap
  • Планы портфеля (бета-версия)
  • Dependency Tracker

Отображение ошибок на досках невыполненных работ (команда)
Пользовательские типы рабочих элементов, невыполненная работа по продукту (процесс)
Пользовательские типы рабочих элементов, taskboard (процесс)

  • Boards > плата продукта
  • Журнал > ожидания невыполненной работы по продукту
  • Средство сопоставления невыполненных работ >
  • Спринты невыполненной работы > спринта
  • Спринты > taskboard
  • Скорость

Пользовательские типы рабочих элементов, невыполненная работа портфеля (процесс)
Дополнительные невыполненные работы портфеля (процесс)

  • Boards > доски портфеля
  • Невыполненная работа портфеля портфель невыполненной работы >
  • Средство сопоставления невыполненных работ >
  • Скорость

Настраиваемый рабочий процесс (процесс)

  • Boards > плата продукта
  • Boards > доски портфеля
  • Спринты > taskboard
  • Диаграмма накопительных потоков
  • Dependency Tracker

Настраиваемое поле (процесс)

  • Boards > плата продукта
  • Boards > доски портфеля

Пути к областям, группы продуктов и управление портфелем

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

Пути к области и иерархическое группирование

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

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

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

Путь к области — зависимые средства

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

Совет

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

Чтобы использовать следующие средства, команды должны подписываться на пути к областям:

Пути к областям и назначения команд

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

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

Пути к областям и назначения команд

  • Вы создаете иерархические пути к областям для поддержки подкатегорий функций и областей продукта.
  • Чтобы предоставить представление портфеля, необходимо назначить несколько путей к областям и включить подобласти в группу управления портфелем.
  • Пути к областям, назначенные команде, определяют, какие рабочие элементы фильтруются в представлении команды: невыполненная работа по продукту, невыполненная работа портфеля, планы доставки или другое средство планирования портфеля.
  • Группирование рабочих элементов в родительской функции или ситуации определяет, какие представления свертки поддерживаются и как работает в представлении календаря, например на временной шкале компонентов и в плане ситуации.

Перед добавлением команд рекомендуется ознакомиться со следующими статьями:

Рекомендации

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

Совет

  • Рабочие элементы могут быть назначены только отдельным сотрудникам. Поэтому при определении рабочих элементов определите, сколько рабочих элементов требуется для назначения работы тем, кто будет выполнять задачу для выполнения работы.
  • Выберите поле имя узла в качестве параметра столбца, чтобы просмотреть узел конечной области в списке невыполненной работы или на плате доски.
  • Не создавайте связи "родители-потомки" между рабочими элементами одного типа, такими как «история», «ошибка-ошибка», «задача-задача».

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

Обрабатывать ошибки как требования или задачи

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

При использовании процесса Scrum Настройка по умолчанию заключается в отслеживании ошибок и элементов невыполненной работы по продукту (PBI). Если вы работаете в проекте на основе процессов Agile или CMMI, ошибки не отображаются в невыполненной работе автоматически.

Обратитесь к команде, чтобы определить, как им нужно управлять ошибками. Затем измените параметры команды соответствующим образом.

Совет

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

Добавление системных типов рабочих элементов в невыполненную работу

Если вы хотите отследить проблемы или препятствия вместе с вашими требованиями или в невыполненной работе портфеля, можно добавить их в пользовательский унаследованный процесс. Дополнительные сведения см. в разделе Настройка невыполненной работы или доски (процесс наследования).

Управление сводностью, иерархией и портфелем

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

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

Индикаторы выполнения, отображающие свертку по рабочим элементам

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

Снимок экрана, показывающий сводное представление хода выполнения планов доставки четырех сценариев.

Пути итераций, спринты, выпуски и управление версиями

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

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

Пути итерации, сгруппированные

Примечание

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

Определите пути итерации и назначьте их командам, если вы хотите использовать следующие средства:

Совет

Если команда не подписана или не выбрала путь итерации, этот путь итерации не будет отображаться в представлении или средстве команды.

Отслеживание времени

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

Однако некоторым организациям требуется отслеживание времени для поддержки других целей, например для выставления счетов или обслуживания записей о распределении времени. Значения времени для предполагаемой работы и выполненной работы представляют интерес. Процессы Agile и CMMI предоставляют эти поля —исходную оценку, завершенную работу, оставшуюся работу— для использования во время отслеживания. Их можно использовать для этой цели. однако Azure Boards предоставляет ограниченную встроенную поддержку отслеживания времени. Вместо этого вы можете использовать расширение Marketplace для поддержки дополнительных требований к отслеживанию времени.

Примечание

Поля Исходная оценка, завершенная работа, оставшиеся трудозатраты были разработаны для поддержки интеграции с Microsoft Project. поддержка интеграции с Microsoft Project является устаревшей для Azure DevOps Server 2019 и более поздних версий, включая облачную службу.

Обработка изменений, влияющих на все команды

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

Пользовательские поля

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

Примечание

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

Пользовательские типы рабочих элементов

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

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

При добавлении пользовательского типа рабочего элемента (WIT) в одну из следующих категорий отслеживания работы команда разработчиков влияет на следующие способы:

  • Категория задачи:
    • Дочерние рабочие элементы нового WIT отображаются в невыполненной работе по продукту
    • Рабочие элементы, основанные на новом WIT, отображаются в невыполненной работе спринта и Таскбоардс
  • Категория требований:
    • Рабочие элементы, основанные на новом WIT, отображаются на доске невыполненной работы по продукту и Канбан
    • Каждая команда должна настроить доску Канбан для поддержки нового WIT.
  • История или категория характеристик:
    • Рабочие элементы, основанные на новом WIT, отображаются в соответствующих невыполненных работах портфеля и на досках Канбан.
    • Каждая команда должна настроить доски Канбан для поддержки нового WIT.
    • Новый WIT может не отображаться в одном или нескольких средствах планирования портфеля.

Настраиваемый рабочий процесс

Каждый процесс поддерживает рабочий процесс по умолчанию. Этот рабочий процесс определяет столбцы по умолчанию, которые отображаются на досках Канбан и Таскбоардсе спринта.

Состояния рабочего процесса: пользовательская история, гибкий процесс

Состояние рабочего процесса пользовательской истории, гибкий процесс

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

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

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

Совокупная схема потока

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

Кто можете вносить изменения?

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

Изменения на уровне процесса

для создания, изменения и управления унаследованными процессами и их применения к проектам необходимо быть членом группы " администраторы коллекции Project". Или же необходимо иметь соответствующие разрешения Создание процесса, Удаление процесса, изменение процессаили Удаление поля из набора организация , чтобы Разрешить. См. раздел Настройка разрешений и доступа для отслеживания работы, Настройка унаследованного процесса.

Дополнительные сведения см. в следующих статьях:

изменения уровня Project

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

Чтобы добавить, изменить и управлять путями областей или путями итераций в определенном узле, необходимо иметь одно или несколько из следующих разрешений, имеющих разрешение:

  • Создать дочерние узлы
  • Удалить этот узел
  • Изменить этот узел
  • Просмотр разрешений в этом узле

Дополнительные сведения см. в следующих статьях:

Изменения на уровне группы

все средства команды могут быть настроены администратором команды или членом групп администраторов Project Project или администраторов коллекции.

Администраторы команды выполняют следующие операции:

  • Добавление членов команды
  • Подпишитесь на пути к области и итерации
  • Настройка невыполненной работы и других общих параметров команды
  • Настройка досок Канбан
  • Управление уведомлениями команды

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

Возможные дальнейшие действия

Azure Boards

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

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

Примечание

Эта статья относится к Azure DevOps Services. Большинство рекомендаций действительно для облачных и локальных версий. Однако в настоящее время некоторые функции, описанные в этой статье, такие как ROLLUP, Analytics и некоторые средства планирования портфеля, доступны только для облака.

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

Что следует учесть?

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

Основные элементы, которые следует учитывать при структурировании проекта:

На уровне проекта:

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

На уровне команды:

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

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

Типы рабочих элементов и невыполненные работы портфеля

Первый вариант, сделанный при отслеживании работы, — это процесс, выбранный при создании проекта. Сравнение каждого процесса см. в разделе Выбор процесса. Каждый процесс — Agile, Basic, Scrum и CMMI — поддерживает набор иерархий типов рабочих элементов. Эта иерархия поддерживает невыполненную работу по продукту и невыполненную работу портфеля.

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

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

Концептуальное изображение, тип рабочего элемента Agile

Каждая команда может настроить способ управления ошибками (на том же уровне, что и пользовательские истории или задачи), настроив параметр Работа с ошибками . Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе Agile Process.

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

Задачи и основные результаты в виде дополнительных невыполненных работ портфеля

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

Параметры отслеживания работы

Поддерживаемые задачи и средства