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

Рекомендации по управлению проектами по методике Agile

  • Статья

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

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

Примечание.

Если ваша команда стремится к практике методов Kanban или Scrum, см . сведения о Досках и Канбане или руководствах по реализации Scrum.

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

Настройка команд

Azure Boards предоставляет каждой команде набор средств Agile для планирования и отслеживания работы. Каждый проект определяет команду по умолчанию, которую можно начать сразу же. Если у вас есть несколько команд разработки или функций, рекомендуется определить команду в Azure DevOps для каждой команды функций. Таким образом, каждая команда может работать автономно при совместной работе друг с другом.

Советы по рекомендациям:

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

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

Настройка спринтов

Спринты, указанные путем итерации, определяются для проекта, а затем выбираются командами. Спринт может варьироваться от одной недели до четырех недель или более. Кроме того, можно определить спринты в иерархии, включающую поезда выпуска. Вы назначаете работу спринтам, которые команды фиксируют для доставки в конце спринта. Эти средства Azure Boards используют назначения спринта для невыполненных журналов, доски задач и планов прогнозирования и доставки. Дополнительные сведения см. в разделе "Реализация методик scrum" и "Проверка планов доставки группы".

Советы по рекомендациям:

  • Определите спринт для использования всеми командами в группе продуктов.

  • Определите по крайней мере шесть или более итераций, которые поддерживают планирование на ближайшие 6–12 месяцев.

  • Определите, как команды используют итерации для управления элементами невыполненной работы.

    • Неназначенные работы спринта назначаются невыполненной работе по умолчанию.
    • Неназначенные работы спринта назначаются назначенному будущему спринту невыполненной работы.

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

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

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

Если проект основан на другом процессе, например базовой, scrum или интеграции модели зрелости возможностей (CMMI), у вас есть следующие варианты. Каждая команда определяет, как они хотят отслеживать ошибки.

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

Схема с типами рабочих элементов Agile.

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

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

Примечание.

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

Советы по рекомендациям:

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

  • Быстро добавьте функции или требования из невыполненной работы и заполните подробные сведения позже.

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

    • Для Agile используйте тип рабочего элемента "История пользователя".
    • Для "Базовый" используйте тип рабочего элемента проблемы.
    • Для Scrum используйте тип рабочего элемента невыполненной работы продукта.
    • Для CMMI используйте тип рабочего элемента "Требование".

  • Используйте тип рабочего элемента ошибки для записи дефектов кода.

  • Сопоставляйте требования к функциям для отслеживания хода выполнения на уровне управления проектами.

  • Требования к размеру, которые необходимо выполнить в спринте.

  • Функции размера, которые необходимо выполнить в спринте или нескольких спринтах.

  • Размер эпических рабочих элементов для доставки ежеквартально или в некоторые вехи цели.

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

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

Если у вас есть более крупные инициативы или сценарии, требующие доставки нескольких функций, сгруппировать их в категорию Epic с помощью ссылок родительского-дочернего элемента.

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

Создание плана продукта

Создайте план продукта с помощью невыполненной работы функций. Затем команда разработчиков создает план продукта с помощью невыполненной работы продукта. Периодически следует просматривать и уточнять планы продукта.

Невыполненная работа функций

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

Снимок экрана: невыполненная работа функций.

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

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

Снимок экрана: невыполненная работа продукта.

Уточнение каждой невыполненной работы

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

  • Определите выполняемую работу.
  • Переупорядочение рабочих элементов с помощью метода перетаскивания, чтобы они отображались в порядке приоритета.
  • Откройте рабочие элементы и добавьте сведения.
  • Назначьте работу членам команды или спринтам.
  • Захват технического долга и нефактурной работы, необходимой для поддержки здоровой экосистемы доставки.
  • Сопоставить непарентную работу с функциями, к которым она принадлежит.
  • Оцените размер требований для определения скорости команды и поддержки прогнозирования (необязательно).

Совет

Вы можете отслеживать скорость команды на основе оценок, назначенных завершенной работе или простого количества рабочих элементов, завершенных во время спринтов. Чтобы использовать функцию прогнозирования, необходимо назначить значение полю "Точки истории", "Усилия" или "Размер ". Если вы не хотите оценить требования, можно просто назначить значение 1 оценкам требований, а затем использовать средство прогнозирования на основе количества рабочих элементов.

Советы по рекомендациям:

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

Дополнительные сведения см. в разделе:

Использование тегов для поддержки запросов и фильтрации

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

На следующем рисунке показана доска, отфильтрованная по веб-ключевому слову, отображающего карточки с тегом Web .

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

Советы по рекомендациям:

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

Дополнительные сведения см. в разделе:

Планирование прогноза и вехи

Чтобы получить представление о функциях, которые могут отправляться, используйте средство прогнозирования. Для этого средства необходимо предоставить оценки в поле "Точки истории", "Усилия" или "Размер " для каждого требования. Если вы хотите прогнозировать простое количество рабочих элементов, назначьте значение 1 оценкам требований.

Упорядочение невыполненной работы функций в порядке приоритета

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

Здесь в журнале функций показана последовательность функций для отправки.

Снимок экрана: невыполненная работа функций, упорядоченная родительским элементом компонентов.

Упорядочение невыполненной работы требований на основе родительских функций

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

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

Прогнозирование невыполненной работы требований

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

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

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

Обновление доски компонентов

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

Снимок экрана: доска компонентов с обновленными путями итерации.

Планирование вехи

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

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

Управление зависимостями

В Microsoft Project вы управляете задачами, которые зависят от завершения других задач, связывая их. Чтобы управлять зависимостями в Azure Boards, можно добавить аналогичную компоновку, добавив типы ссылок "Предшественник/преемник" в рабочие элементы. Добавьте эти ссылки из диалогового окна добавления ссылки для рабочего элемента.

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

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

Снимок экрана: диалоговое окно

Визуализация связей рабочих элементов

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

Снимок экрана: строки зависимостей между несколькими рабочими элементами.

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

Снимок экрана: визуализация связей рабочих элементов.

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

Azure Boards не предоставляет собственное представление критического пути. Гибкие методологии предпочитают минимальный жизнеспособный продукт (MVP) по поводу управления критическими путями. Используя MVP, вы определите самый короткий путь и зависимости путем приоритета типов рабочих элементов Epic, Feature, User Story и Task. Дополнительные сведения см. в статье "Критически важный путь для проектов Agile" и "Запуск запуска на основе Azure DevOps".

Советы по рекомендациям:

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

Примечание.

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

Дополнительные сведения см. в разделе:

Работа в спринтах

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

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

Снимок экрана, на котором показана диаграмма очистки спринта аналитики.

Советы по рекомендациям:

Для каждого спринта выполните следующие задачи:

  • Запланируйте каждый спринт с помощью вашей команды.
  • Используйте невыполненную работу команды для проверки доставки спринта.
  • Убедитесь, что каждому рабочему элементу спринта назначен член группы.
  • Убедитесь, что каждый рабочий элемент ограничен для завершения в спринте.
  • Убедитесь, что критерии принятия для работы четко определены и понятны.
  • Обновите состояние рабочих элементов спринта, так как работа перемещается с нового на "Активный" в завершенные состояния, отслеживая спринт сгорание.
  • Обратитесь к другим командам по зависимостям, от которых зависит работа вашей команды.
  • Мониторинг хода выполнения спринта с помощью диаграммы спринта.

Дополнительные сведения см. в разделе:

Просмотр результатов выполнения и функций

Ниже приведены три основных средства, которые следует использовать для проверки хода выполнения и конечных результатов:

  • Доска компонентов
  • Невыполненная работа с столбцами свертки
  • Планы выполнения

Доска компонентов

Доска функций — это еще одно место для просмотра хода выполнения и обеспечения непрерывного потока доставки. На следующем рисунке показана настраиваемая доска функций, в том числе столбцы выполнения, такие как Необходимость получения дополнительных сведений, On Deck, In Progress и Customer Rollout. Эти столбцы предоставляют более естественный набор состояний, так как функции получают предлагаемые, исследовательские, разработанные, разработанные, разработанные, а затем развернутые в рабочей среде.

Снимок экрана: доска компонентов с настраиваемыми столбцами.

Свертка

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

Снимок экрана: невыполненная работа функций с параметром столбца индикаторов хода выполнения.

Планы доставки и несколько конечных результатов команды

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

Снимок экрана: выноски планов доставки.

Элементы интерактивного плана

Советы по рекомендациям:

  • Настройте доску функций для поддержки процессов вашей команды.
  • Добавьте поля в карточки, чтобы можно было быстро и легко обновлять их значения.
  • Обновите путь итерации (спринт) функций по мере получения ясности о том, когда они передаются.
  • Просмотрите доску функций, чтобы обсудить состояние, блоки/проблемы/ риски/изменения и состояние обновления.
  • Используйте функцию фильтра, чтобы сосредоточиться на помеченных элементах, назначаемых функциями, определенными спринтами и т. д.
  • Добавьте столбцы свертки в невыполненную работу функции, чтобы отслеживать общий ход выполнения на основе завершения количества рабочих элементов.
  • Используйте планы доставки для просмотра функций для нескольких команд для обсуждения зависимостей между командами.

Дополнительные сведения см. в разделе:

Улучшение процесса

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

  • Планирование спринтов.
  • Задайте цели спринта.
  • Проводите регулярные ретроспективы.

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

  • Что вы узнаете о ваших клиентах? Что необходимо знать?
  • Какие данные измеряются? Можно ли действовать? Какие данные необходимо измерять?
  • Как происходит поток доставки? Как ожидалось? Где можно улучшить?
  • Могут ли ваши члены команды сделать все возможное? Какие инструменты или сведения помогут им улучшить?
  • Насколько хорошо предоставлен общий доступ к информации? Насколько хорошо работают команды?
  • Насколько хорошо ваша команда управляет техническим долгом и закрывает ошибки?

Некоторые из средств Agile, которые можно использовать для поддержки улучшения процесса, являются скорость команды, панели мониторинга команды и расширение Ретроспективы Marketplace.

Скорость команды

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

Снимок экрана: пример диаграммы скорости команды.

Командные панели мониторинга

Teams может определять панели мониторинга для совместного использования информации и отслеживания данных в режиме реального времени о ходе выполнения работы.

Снимок экрана: пример панели мониторинга команды.

Советы по рекомендациям:

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

Дополнительные сведения см. в разделе:

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

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

Отраслевые статьи