Реализация масштабируемой гибкой платформы® в Azure Boards

Статья
04/04/2024

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Многие предприятия получают выгоду от отдельных команд Agile. Больший интерес растет, чтобы масштабировать методики Гибкой разработки по мере роста организации. Потребность предприятий в просмотре прогресса многих команд Agile и в портфеле продолжает увеличиваться. Для решения этих потребностей многие предприятия приняли масштабируемую гибкую платформу® (SAFe®).

Если вы знакомы с Scrum, но не знакомы с SAFe, см . статью SAFe® Studio Framework.

Azure Boards поддерживает методики SAFe® через свои автономные команды, невыполненные работы, доски, отчеты и метрики. В этой статье описано, как артефакты Azure Boards поддерживают методики и артефакты SAFe.

Масштабируемая гибкая платформа®
Essential SAFe®
Портфель SAFe®
SaFe® для крупных решений
Быстрое сопоставление ссылок
Реализация SAFe® в Azure Boards

Примечание.

Эта статья является одним из наборов руководств по Масштабируемой гибкой платформе®, которые применяются к Azure Boards и Azure DevOps Services. Большая часть рекомендаций допустима как для облачных, так и для локальных версий. Однако некоторые функции и процедуры относятся к облаку или последней версии Azure DevOps Server.

Scaled Agile Framework®

SAFe® решает, как видение портфеля выполняется иерархией команд, все обеспокоены конкретными целями. Эта платформа разбивает эпические элементы на функции и истории. Teams работают над этими элементами в спринтах и предоставляются с помощью программных добавок (PIS) и выпусков поездов. Кроме того, невыполненная работа портфеля может отслеживать конечные типы, которые сопоставляют потоки стоимости и связанные бюджеты.

Обзор архитектуры SAFe® версии 5.0

SAFe® и Scaled Agile Framework являются зарегистрированными товарными знаками Scaled Agile Inc.

SaFe® 5.0 Business Agility

Многие методики SAFe® включают рост культуры, которая поддерживает гибкость, выравнивание и автономию, в то время как клиент ориентирован.

В следующих статьях рассматриваются некоторые способы поддержки гибкости бизнеса и гибкой культуры Azure Boards:

Essential SAFe®

Essential SAFe® требует поддержки артефактов и методик, показанных на следующем плакате.

Все эти артефакты и методики поддерживаются Azure Boards.

Истории, функции и средства включения: реализованы как рабочие элементы, которые фиксируют сведения и состояние работы. Эти рабочие элементы автоматически отображаются в невыполненных работах и досках команды.
Невыполненные работы команды и невыполненные работы по программам: реализованы как невыполненные работы группы, которые фильтруют рабочие элементы, назначенные команде, и поддерживают приоритеты и группирование работ.
Scrum и Kanban: практики, которые полностью поддерживаются с помощью досок, невыполненных журналов и задач, команд и спринтов.
Итераций, инноваций и планирования (IP) итерации, добавок программ (PI), вех и выпусков: реализован через плоский список или иерархическую конфигурацию путей итерации.
Обучение гибких выпусков: реализовано набором команд Agile и команд программ, настроенных для поддержки определенных представлений команды и программ.
Цели pi, цели команды и контекст решения: Teams может использовать встроенный вики-сайт проекта для совместного использования целей, целей, сведений о клиентах и требованиях к решению.

Общие сведения о том, как Azure Boards реализует Scrum и Kanban, см. в статье "О спринтах", "Scrum" и "Управление проектами" и "О советах" и "Канбан".

Портфель SAFe®

Portfolio SAFe® добавляет поддержку управления портфелями с помощью эпических, включения и потоков ценности.

Azure Boards обеспечивает поддержку следующих компонентов портфеля:

Epics: сопоставление с типом рабочего элемента Epic и разрешением отслеживания, группировки и свертки дочерних элементов.
Невыполненные работы портфеля: реализован в качестве невыполненной работы портфеля, которая поддерживает фильтрацию работы на основе проверки бизнес-потребностей.
Портфельное видение и стратегические темы: владельцы бизнеса и руководители портфеля могут использовать встроенный вики-сайт проекта, чтобы поделиться своим видением, целями и целями.
Потоки значений: потоки значений можно отслеживать с помощью тегов или настраиваемых полей.
Бережливые бюджеты: сведения о бюджете можно записать в пользовательских полях и свернуть, чтобы получить видимость уровней компонента и эпического уровня.
Ключевые показатели эффективности: несколько отчетов и мини-приложений панели мониторинга предоставляют метрики вне поля. Power BI и служба аналитики обеспечивают поддержку быстрого создания пользовательских отчетов.

SaFe® для крупных решений

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

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

Полный SAFe®

Full SAFe включает три уровня Essential SAFe, Large Solution SAFe и Portfolio SAFe®®®.®

Сопоставление артефактов SAFe® с Azure Boards

В следующей таблице сопоставляется термины или артефакты SAFe® с эквивалентным термином или артефактом Azure Boards. Выберите ссылку для получения сведений о реализации.

Термин или артефакт SAFe®

Термин или артефакт Azure Boards

Гибкие команды

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

Обучение гибких выпусков (ART)

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

сведения о бюджете;

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

Возможности

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

Необходимые условия

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

Ситуации

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

Функции

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

Итерация инноваций и планирования (IP)

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

Итерация

Milestones

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

Невыполненная работа портфеля

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

Портфель Канбан

Совет Portfolio Epics. Совет команды портфеля отображает невыполненную работу Epics в виде карточек в интерактивной, настраиваемой и фильтруемой доске.

Видение портфеля

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

Невыполненная работа программы

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

Программа Канбан

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

Путь итерации программы (PI)

Путь итерации. Пути итерации определяют поле времени для проекта с датами начала и окончания. Пути итерации можно определить от одной недели до 12 недель или более.

Ретроспективы и отзывы

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

Дорожная карта

Планы доставки, временная шкала компонентов. Azure Boards предоставляет настраиваемые и интерактивные представления для просмотра схем и доставки команд.

Общие службы

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

Решения

Решения. Решения можно представить с помощью пользовательского типа рабочего элемента решения.

Невыполненная работа решения

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

Стратегические темы

Вики-сайт. Стратегические темы, похожие на портфельное видение, можно записать в вики-сайте проекта.

Истории

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

Невыполненная работа команды

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

Команда Канбан

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

Потоки значений

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

Реализация SAFe® в Azure Boards

Каждая из следующих статей в этом наборе руководств содержит сведения о настройке, настройке и использовании Azure Boards для реализации программ и проектов SAFe®.

Следующие шаги

Сопоставление концепций SAFe® с артефактами Azure Boards

Масштабирование гибкой разработки до крупных команд
Культура Agile
Методики масштабирования
Сведения о Sprints, Scrum и управлении проектами
О досках и Канбане
Масштабируемая гибкая платформа: сайт ресурсов SAFe®.
Масштабирование метрик Agile и SAFe® с помощью TFS: запись блога, которая иллюстрирует отчет SQL Server, разработанный InCycle для иллюстрации того, как TFS можно использовать для поддержки масштабируемой гибкой или SAFe.

О авторах

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

Филлип Eng является старшим архитектором Корпорации Майкрософт, цифровым поиском и руководством.
Hosam Kamel — это технология, профессиональная для Microsoft и ALM Ranger.
Вилли-Питер Шауб является бывшим менеджером программы с Visual Studio ALM Rangers в Центре разработки Microsoft Canada. Вы можете следовать Вилли-Питеру на Twitter на twitter.com/wpschaub.

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

Гордон Beeming является разработчиком программного обеспечения в Деривко в солнечном городе Дурбан, Южная Африка. Он проводит большую часть своего времени взломать на клавиатуре в Visual Studio или со своей семьей отдыха. Его блог находится на gordonbeeming.xyz , и вы можете следовать ему на Twitter на twitter.com/gordonbeeming.
Брайан Блэкман является главным консультантом с microsoft Premier Developer, акцентируя внимание на влиянии партнеров И предприятий на инженерию и marketplace. Он имеет MBA, и является CSM, CSP, MCSD (C++) и MCTS и является Visual Studio ALM Ranger. Когда он не Ruck Mastering и участие в проектах Visual Studio ALM Ranger, он тратит свое время на написание кода, создание и доставку семинаров, а также консультации в различных концентрациях, особенно помогая организациям в их поиске бизнес-гибкости.
Gregg Boer — главный руководитель программы в Корпорации Майкрософт. Gregg является владельцем продукта для гибкого управления, предоставляемого Azure DevOps и локальными TFS.
Кэтрин Эллиотт является старшим техническим писателем в Корпорации Майкрософт.
Сьюзан Феррелл является старшим техническим писателем и Visual Studio ALM Ranger.
Вилли-Питер Шауб является бывшим менеджером программы с Visual Studio ALM Rangers в Центре разработки Microsoft Canada. С середины 80-х годов он стремится к простоте и поддержанию в программном проектировании. Вы можете следовать за ним в Twitter на twitter.com/wpschaub.
Особое спасибо следующим техническим экспертам за изучение этой статьи: Майк Дуглас (независимый консультант, ALM Ranger), Ричард Hundhausen (независимый консультант, ALM Ranger) и Билл Эйс (независимый консультант, ALM Ranger).

Поделиться через

Реализация масштабируемой гибкой платформы® в Azure Boards