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

  • Статья

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

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

Определение необходимости изменения

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

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

Минимизация изменений

Свести к минимуму ненужные изменения, указав следующие сведения:

  • Очистить требования и критерии принятия
  • Очистка область проекта и приоритетов
  • Четкий процесс управления изменениями, согласованный командой
  • Хорошие оценки плановой работы
  • Согласованные запросы на новую работу
  • Требования
  • Хороший обмен данными в команде при возникновении изменений
  • Входные данные заинтересованных лиц и клиентов вокруг запросов на изменение
  • Участники команды комфортно вызывают проблемы по мере их возникновения

Гибкие рекомендации по управлению изменениями

Примечание.

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

Чтобы устранить проблемы, возникающие из-за изменений, руководители проектов Agile принимают множество рекомендаций. Эти методики разделены на следующие группы: управление процессом, управление изменениями на уровне плана продукта, управление спринтами и рассмотрение критериев изменения.

Управление процессом

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

Совет

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

Управление изменением на уровне плана продукта

  • Непрерывное уточнение и приоритет плана продукта и невыполненной работы продукта
  • Убедитесь, что потребности клиента понятны и правильно область и взаимодействуют
  • Анализ невыполненной работы продукта для зависимостей и рисков
  • Разработка планов на непредвиденные случаи
  • Анализ и анализ запросов на изменение
  • Определение область эффекта запросов на изменения в текущих и запланированных работах
  • Оценка рисков принятия или отклонения изменения
  • При необходимости используйте форму управления изменением света

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

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

Совет

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

Рассмотрите критерии изменения

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

  • Служит ли она цели спринта?
  • Существует ли четкое бизнес-значение для изменения?
  • После выпуска вы планируете использовать результат изменения область?
  • Что такое срочность запроса на изменение?
  • Если новая область добавлена в невыполненную работу с спринта, есть ли что-то, что можно удалить?

Отслеживание изменений

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

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

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

Использование формы запроса на изменение

Определите тип рабочего элемента запроса на изменение, например в следующем изображении для процесса интеграции модели зрелости возможностей (CMMI).

Снимок экрана: форма рабочего элемента запроса на изменение.

Форма фиксирует эффекты изменения в следующих областях:

  • Архитектура
  • Взаимодействие с пользователем
  • Тест
  • Проектирование и разработка
  • Технические публикации

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

Убедитесь, что критерии принятия хорошо определены

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

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

Мониторинг и отчет об изменениях

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

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

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

Скорость команды и незапланированная работа

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

Спринт сгореть и область ползунок

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

Получение уведомлений об изменениях

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