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

Рекомендации по управлению проектами по методике 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, отображающая карточки с тегом Web.

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

Советы по лучшим практикам:

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

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

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

Чтобы получить понимание того, какие функции могут выпускаться, используйте инструмент прогнозирования. Для использования этого инструмента требуется, чтобы вы предоставили оценки для поля Story Points, Effort или Size для каждого требования. Если вы хотите прогнозировать простое количество рабочих элементов, назначьте значение 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, В процессе и Внедрение у клиента. Эти столбцы предоставляют более естественный набор состояний, так как функции получают предлагаемые, исследуемые, спроектированные, разработанные, а затем развернутые в производство.

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

Свертка

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

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

Планы поставок и многочисленные командные задачи

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

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

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

Советы по лучшим практикам:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Советы по лучшим практикам

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

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

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

Конфигурация и кастомизация Azure Boards

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