Сопоставление концепций SAFe® с артефактами Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Если вы хотите использовать масштабируемую гибкую платформу (SAFe), вы можете настроить проект Azure Boards для отслеживания доставки SAFe®®. Так же, как Azure Boards поддерживает методики Scrum и Agile, она может поддерживать SAFe® и большое количество команд для совместной работы в Epics, охватывающих выпуски.
В этом руководстве показано, как следующие артефакты SAFe® сопоставляют с определенными артефактами Azure Boards.
- Команды saFe® Agile, program и portfolio teams
- Доставить SAFe®, такие как эпические, особенности и истории
- Представления продукта, программы и портфеля SAFe®
- Поезда выпуска SAFe®, спринты и другие почтовые ящики времени
- Цели и цели Итерации SAFe®
- Потоки и бюджеты SAFe® Value
- SaFe® Portfolio Vision и стратегические темы
- Стратегии SAFe®
- Вехи и события SAFe®
- SAFe® Ретроспективы и отзывы
Общие сведения о том, как Azure Boards реализует Scrum и Kanban, см. в статье "О спринтах", "Scrum" и "Управление проектами" и "О советах" и "Канбан".
Примечание.
Эта статья является одним из наборов руководств по Масштабируемой гибкой платформе®, которые применяются к Azure Boards и Azure DevOps Services. Большая часть рекомендаций допустима как для облачных, так и для локальных версий. Однако некоторые функции и процедуры относятся к облаку или последней версии Azure DevOps Server.
На следующем рисунке показано, как настроить Azure Boards для поддержки трехуровневой иерархии команд и сопоставления команд с соответствующими областями и путями итерации. Примеры сборки из процесса Agile, однако изменения могут применяться к любому проекту и процессу, размещенного в Azure Boards.
В примерах ниже показано, как настроена трехуровневая иерархия команд с помощью иерархических путей к областям. Примеры сборки из процесса Agile, однако вы можете применить эти изменения к любому проекту, размещенного в Azure Boards.
Команды гибких возможностей, программ и портфеля
Azure Boards поддерживает каждую команду, чтобы иметь собственное представление о своей работе. Настроив иерархическую структуру команды, каждая команда может сосредоточиться на своей работе и выполнить их работу до следующего уровня в иерархии команд.
Чтобы поддерживать команды SAFe®, вы перенастроите команду по умолчанию в качестве команды портфеля для управления эпическими эпопеями. Затем вы создаете подкамы для работы на уровне программы и работы на уровне команды. Можно отслеживать работу между командами и на каждом уровне.
Истории, функции, эпические характеристики, средства включения и возможности
Все рабочие и конечные листы фиксируются в рабочих элементах. Каждый рабочий элемент связан с определенным типом рабочего элемента с предопределенным рабочим процессом. Каждый процесс Azure Boards обеспечивает поддержку определенных типов рабочих элементов, которые можно использовать для отслеживания любого из доставки SAFe®.
Типы рабочих элементов, доступные для вас, основаны на процессе, используемом при создании проекта — Agile, Basic, Scrum или CMMI, как показано на следующих изображениях.
На следующем рисунке показана иерархия для рабочего элемента невыполненной работы процесса Agile:
Истории пользователей и задачи используются для отслеживания работы.
Ошибки отслеживают дефекты кода.
Эпические и функциональные возможности используются для группирования работы в более крупных сценариях.
Каждая команда может настроить управление рабочими элементами ошибок на том же уровне, что и "История пользователя" или "Рабочие задачи", настраивая параметр "Работа с ошибками ". Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе "Гибкий процесс".
Элементы в невыполненной работы могут называться " Истории пользователей" (гибкие) проблемы (базовый), элементы невыполненной работы продукта (Scrum) или требования (CMMI). Все четыре похожи: они описывают ценность клиента для доставки и завершения работы.
Вы можете отслеживать включение с помощью пользовательских историй или функций, а также возможностей с помощью функций или эпических элементов. Кроме того, если у вас есть конкретные потребности в отслеживании и отчетности, можно добавить настраиваемые типы рабочих элементов для отслеживания этих типов доставки. Дополнительные сведения см. в разделе "Настройка досок Azure" и "Добавление настраиваемых типов рабочих элементов".
Рабочие элементы обеспечивают поддержку следующих задач:
- Добавление условий описания и принятия
- Назначение пути к команде или области и члену проекта
- Обновление состояния и назначение итерации или спринта
- Связывание рабочих элементов, присоединение файлов, добавление тегов
- Добавление комментариев и просмотр потока обсуждения
Невыполненные работы по продуктам и портфелям позволяют командам быстро добавлять и определять приоритеты своих пользовательских историй, функций и эпических событий. Дополнительные сведения о рабочих элементах и типах рабочих элементов см. в разделе "Отслеживание работы с историями пользователей", проблемами, ошибками, функциями и эпическими элементами.
Невыполненная работа команды и доски
Невыполненные работы SAFe® сопоставляют с командами, программами и портфелями невыполненных работ. Вне поля процесс Agile поддерживает уровни невыполненной работы пользователей, функций и эпических невыполненных работ. Иерархическая структура невыполненной работы показывает работу, выполненную для поддержки функций и пользовательских историй в ходе эпического процесса.
Вы можете настроить невыполненную работу и доски, даже добавив невыполненные журналы портфеля, как описано в разделе "Настройка досок Azure", настройка невыполненных работ.
Представление доски Kanban для каждой невыполненной работы настраивается каждой командой.
Увеличение программы, выпуски и спринты
SaFe® Release Trains, Release, Release, Iterations, ProgramCrements (PIs) и Sprints легко сопоставляют пути итерации. Предоставляя общий доступ к итерации в иерархии команд, вы управляете выпусками согласованно.
Поскольку эпические эпосы могут охватывать несколько поездов выпуска, команда портфеля не связана с какими-либо конкретными итерациями. Команды программ отслеживают доставить свои функции, которые передаются с идентификатором личных данных. И команды функций работают в Sprints, чтобы завершить несколько историй. Каждая команда выбирает, какие итерации поддерживают их для отслеживания их ориентированного набора конечных результатов.
Цели и цели итерации
Методики SAFe® включают команды гибких выпусков, определяющие цели и цели итерации. Мы рекомендуем использовать вики-страницы проекта или панели мониторинга группы для сбора сведений о команде. Панели мониторинга проекта и группы поддерживают Markdown для добавления и форматирования сведений.
Дополнительные сведения см. далее в этой статье.
Потоки стоимости и бюджеты
Теги можно использовать для быстрого и простого способа сопоставления функций и эпических элементов с их значением Потоки, стратегических тем и связанных бюджетов. Вы можете добавить настраиваемые поля для записи оценок бюджета для функций, которые затем могут свернуться в Epics.
С помощью тегов, добавляющихся в рабочие элементы, можно:
- Фильтрация любой невыполненной работы или доски Kanban
- Создание запросов на основе тегов и фильтрация результатов запроса по тегам
- Создание диаграмм хода выполнения и трендов или отчетов на основе тегов
Для более надежного сопоставления работы с архитектурой или бизнес-функциями можно указать область значений для каждой эпической, функции или истории.
С помощью свертки можно получить бюджетные оценки для Эпичных элементов из свертки оценок, определенных их дочерним функциям, как показано на следующем рисунке.
Сведения о добавлении настраиваемых полей см. в разделе "Настройка досок Azure" и "Добавление настраиваемого поля".
Использование вики-сайта проекта для поддержки концепции портфеля и стратегических тем
Сведения можно широко использовать в организации с помощью вики-сайта проекта Azure DevOps. Вики-сайт похож на репозиторий Git, который поддерживает добавление и редактирование страниц с помощью Markdown и редактора WYSIWYG. Она выполняет каждую страницу, чтобы легко отслеживать, кто вносил изменения и восстанавливал последние версии.
Используйте вики-сайт проекта для поддержки совместного использования следующих артефактов SAFe®:
- Видение портфеля
- Стратегические темы
- Классификация
- Цели
- Задачи
- Рекомендации, ориентированные на клиента
Дополнительные сведения о вики-сайте проекта см. далее в этой статье.
Вехи и ключевые события
Конец каждой программы инкремента, Спринта, обучения выпуска или инноваций и планирования (IP) представляет естественные вехи SAFe®. Многие вехи связаны с определенными церемониями или практиками, такими как проведение ретроспектив или демонстрация рабочего программного обеспечения.
В Azure Boards можно отслеживать другие типы вех или ключевые события следующим образом.
- Настраиваемое поле, например веха или поле выпуска с предопределенным списком выбора
- Как тег, добавленный в рабочие элементы
- Как рабочий элемент, указывающий целевую дату
- Как однодневный путь итерации
С помощью настраиваемых полей и тегов можно быстро фильтровать невыполненные работы, доски и запросы на основе определенной вехи.
Структура группы общих служб
Ресурсы, которые совместно используются между командами, могут быть представлены через собственную группу функций Agile, например группу разработки пользовательского интерфейса или группу соответствия требованиям безопасности. Они могут управлять невыполненной работой, а также отображаться в невыполненных работах команд, которые они поддерживают.
Здесь мы покажем, как пути к областям назначены команде конструктора пользовательского интерфейса, а затем выборочные пути подареи другим командам Agile. Рабочие элементы, отображаемые на путях к общей области, отображаются на невыполненных работах и досках связанных команд.
Ретроспективы и отзывы
Чтобы поддержать команды, выполняя ретроспективы и отзывы, рекомендуется использовать расширение Ретроспективы Microsoft DevLabs.
Это расширение позволяет командам создавать собственные ретроспективные доски и записывать следующие задачи:
- Сбор отзывов о вех проекта
- Упорядочение и приоритеты обратной связи
- Создавайте и отслеживайте действия, чтобы помочь каждой команде в их процессах улучшения.
Предоставление доступа к информации
Azure Boards предоставляет множество способов обмена информацией.
- Формы рабочих элементов предоставляют поля с форматированным текстом для записи описаний, условий принятия и многого другого. Вложения файлов можно добавлять в рабочие элементы или ссылки на сетевые общие папки.
- Панели мониторинга проектов и команд можно использовать для совместного использования сведений вместе с диаграммами состояния и прогресса и мини-приложениями. Дополнительные сведения см. в разделе "Добавление Markdown" на панель мониторинга.
- Вики-сайт Project предоставляет центральный репозиторий со встроенным элементом управления версиями для совместного использования информации со всеми участниками проекта. При необходимости можно создать другие вики-сайты. Дополнительные сведения см. в разделе "Вики-сайты", READMEs и Markdown.
Дополнительные сведения о поддерживаемых функциях Markdown см. в следующих статьях.
- Руководство по синтаксису использования Markdown в вики-сайте
- Руководство по синтаксису для базового использования Markdown
Следующие шаги
Связанные статьи
Язык и региональные параметры
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по