Подготовка к технической сложности: гибкое управление изменениямиPrepare for technical complexity: Agile change management

Поскольку весь центр обработки данных может быть отозван и воссоздан с помощью одной строки кода, традиционные процессы борются за то, чтобы не отставать от них.When an entire datacenter can be deprovisioned and re-created with a single line of code, traditional processes struggle to keep up. Руководство по облачной инфраструктуре внедрения основано на практических методиках, таких как управление ИТ-услугами (ITSM), Open Group Architecture Framework (ТОГАФ) и др.The guidance throughout the Cloud Adoption Framework is built on practices like IT service management (ITSM), the open group architecture framework (TOGAF), and others. Однако, для обеспечения гибкости и реагирования на изменения в бизнесе, данная платформа формирует такие методы, чтобы соответствовать гибким методикам и подходам DevOps.However, to ensure agility and responsiveness to business change, this framework molds those practices to fit agile methodologies and DevOps approaches.

При переходе к гибкой модели, в которой выделена гибкость и итерация, техническая сложность и управление изменениями обрабатываются иначе, чем в традиционной модели каскадной структуры, в которой основное внимание уделяется линейному ряду этапов миграции.When shifting to an agile model where flexibility and iteration are emphasized, technical complexity and change management are handled differently than they're in a traditional waterfall model focusing on a linear series of migration steps. В этой статье описывается высокоуровневый подход к управлению изменениями в трудозатратах по миграции, основанных на гибкой методике.This article outlines a high-level approach to change management in an agile-based migration effort. В конце этой статьи вы должны иметь общее представление об уровнях управления изменениями и документации, связанных с поэтапным подходом к миграции.At the end of this article, you should have a general understanding of the levels of change management and documentation involved in an incremental migration approach. Для отбора и внедрения гибких методов работы, основанных на этом распознавании, требуется дополнительное обучение и принятие решений.Additional training and decisions are required to select and implement agile practices based on that understanding. Целью данной статьи является подготовка архитекторов облачных решений к содействующему разговору с руководством проекта для объяснения общей концепции управления изменениями в этом подходе.The intention of this article is to prepare cloud architects for a facilitated conversation with project management to explain the general concept of change management in this approach.

Устранение технических сложностейAddress technical complexity

При изменении любой технической системы сложность и взаимозависимость вносят риск в планы проекта.When changing any technical system, complexity and interdependency inject risk into project plans. Миграции в облако не являются исключением.Cloud migrations are no exception. При перемещении тысяч (или десятков тысяч) ресурсов в облако эти риски поддаются усилителям.When moving thousands (or tens of thousands) of assets to the cloud, these risks are amplified. Обнаружение и сопоставление всех зависимостей в большой цифровой среде может занять годы.Detecting and mapping all dependencies across a large digital estate could take years. Лишь немногие компании могут выдержать такой длительный цикл анализа.Few businesses can tolerate such a long analysis cycle. Чтобы сбалансировать потребность в архитектурном анализе и ускорении бизнеса, Cloud Adoption Framework фокусируется на модели INVEST для управления невыполненной работой по продукту.To balance the need for architectural analysis and business acceleration, the Cloud Adoption Framework focuses on an INVEST model for product backlog management. В следующих разделах представлен этот тип модели.The following sections summarize this type of model.

INVEST в рабочих нагрузкахINVEST in workloads

Термин Рабочая нагрузка встречается по всей платформе Cloud Adoption Framework.The term workload appears throughout the Cloud Adoption Framework. Рабочая нагрузка — это единица функциональности приложения, которая может быть перемещена в облако.A workload is a unit of application functionality that can be migrated to the cloud. Это может быть одно приложение, слой приложений или их набор.It could be a single application, a layer of an application, or a collection of an application. Это определение является гибким и может меняться при различных формулировках миграции.The definition is flexible and may change at various phrases of migration. Инфраструктура внедрения в облаке использует термин « инвестиции » для определения рабочей нагрузки.The Cloud Adoption Framework uses the term INVEST to define a workload.

INVEST является общей аббревиатурой во многих гибких методиках написания пользовательских историй или компонентов невыполненной работы по продукту, которые являются единицами выходных данных в гибких инструментах управления проектами.INVEST is a common acronym in many agile methodologies for writing user stories or product backlog items, both of which are units of output in agile project management tools. Измеряемой единицей выходных данных в миграции является перенесенная рабочая нагрузка.The measurable unit of output in a migration is a migrated workload. Cloud Adoption Framework немного изменяет аббревиатуру INVEST, чтобы создать конструкцию для определения рабочих нагрузок.The Cloud Adoption Framework modifies the INVEST acronym a bit to create a construct for defining workloads:

  • Независимое: В рабочей нагрузке не должно быть недоступных зависимостей.Independent: A workload should not have any inaccessible dependencies. Чтобы рабочая нагрузка считалась перенесенной, все зависимости должны быть доступны, а также включены в трудозатраты миграции.For a workload to be considered migrated, all dependencies should be accessible and included in the migration effort.
  • Оборотный документ: При выполнении дополнительного обнаружения изменяется определение рабочей нагрузки.Negotiable: As additional discovery is performed, the definition of a workload changes. Архитекторы, которые планируют миграцию, могут согласовать факторы зависимости.The architects planning the migration could negotiate factors regarding dependencies. Примеры точек согласования могут включать предварительный выпуск функций, предоставляя доступ к функциям в гибридной сети или упаковывая все зависимости в один выпуск.Examples of negotiation points could include prerelease of features, making features accessible over a hybrid network, or packaging all dependencies in a single release.
  • Ценные: Значение в рабочей нагрузке измеряется возможностью предоставления пользователям доступа к рабочей нагрузке.Valuable: Value in a workload is measured by the ability to provide users with access to a production workload.
  • Естимабле: Все зависимости, активы, время миграции, производительность и стоимость облака должны быть естимабле и оцениваться до миграции.Estimable: Dependencies, assets, migration time, performance, and cloud costs should all be estimable and should be estimated prior to migration.
  • Малый размер: Задача состоит в том, чтобы упаковать рабочие нагрузки в одном спринте.Small: The goal is to package workloads in a single sprint. Однако это не всегда применимо.However, this may not always be feasible. Вместо этого, командам рекомендуется планировать спринты и выпуски, чтобы свести к минимуму время, необходимое для переноса рабочей нагрузки на производство.Instead, teams are encouraged to plan sprints and releases to minimize the time required to move a workload to production.
  • Тестируемый: Всегда должно быть определено средство тестирования или проверки завершения миграции рабочей нагрузки.Testable: There should always be a defined means of testing or validating completion of the migration of a workload.

Эта аббревиатура не предназначена для обеспечения строгого соблюдения, но должна направлять в определении термина рабочая нагрузка.This acronym is not intended as a basis for rigid adherence but should help guide the definition of the term workload.

Невыполненная работа по миграции: выравнивание бизнес-приоритетов и времениMigration backlog: Aligning business priorities and timing

Журнал ожидания миграции позволяет относиться к портфелю верхнего уровня о рабочих нагрузках, которые можно перенести.The migration backlog allows you to track your top-level portfolio of workloads that can be migrated. Перед миграцией команде по разработке стратегии облачных вычислений и команде по внедрению облачных вычислений нужно проверить текущие цифровые активы и согласовать список переносимых приоритетных рабочих нагрузок.Prior to migration, the cloud strategy team and the cloud adoption team are encouraged to perform a review of the current digital estate, and agree to a prioritized list of workloads to be migrated. Этот список формирует основу первоначальной невыполненной работы по миграции.This list forms the basis of the initial migration backlog.

Первоначально рабочая нагрузка на невыполненной работе по миграции вряд ли будет соответствовать критериям INVEST, изложенным в предыдущем разделе.Initially, workloads on the migration backlog are unlikely to meet the INVEST criteria outlined in the previous section. Вместо этого они служат логической группировкой активов из первоначального учета в качестве заполнителя для будущей работы.Instead, they serve as a logical grouping of assets from an initial inventory as a placeholder for future work. Эти заполнители могут быть технически неточными, но они служат основой для координации с бизнесом.Those placeholders may not be technically accurate, but they serve as the basis for coordination with the business.

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

Невыполненные работы по миграции, выпуску и итерации отслеживают различные уровни активности во время миграционных процессов.The migration, release, and iteration backlogs track different levels of activity during migration processes.

При возникновении невыполненной работы по миграции команда по управлению изменениями должна стремиться к получению следующей информации о любой рабочей нагрузке, содержащейся в плане.In any migration backlog, the change management team should strive to obtain the following information for any workload in the plan. Как минимум, эти данные должны быть доступны для всех рабочих нагрузок, приоритетных для миграции в следующих двух или трех выпусках.At a minimum, this data should be available for any workloads prioritized for migration in the next two or three releases.

Точки данных о невыполненной работе по миграцииMigration backlog data points

  • Влияние на бизнес.Business impact. Распознавание воздействия на бизнес, которое содержит отсутствие ожидаемых сроков или снижение функциональности во время заморозки окон.Understanding of the impact to the business of missing the expected timeline or reducing functionality during freeze windows.
  • Относительный приоритет бизнеса.Relative business priority. Ранжированный список рабочих нагрузок на основе данных о приоритетах бизнеса.A ranked list of workloads based on business priorities.
  • Владелец компании.Business owner. Задокументируйте одного человека, ответственного за принятие бизнес-решений в отношении этой рабочей нагрузки.Document the one individual responsible for making business decisions regarding this workload.
  • Технический владелец.Technical owner. Задокументируйте одного человека, ответственного за технические решения в отношении этой рабочей нагрузки.Document the one individual responsible for technical decisions related to this workload.
  • Ожидаемые сроки.Expected timelines. Когда миграция запланирована к завершению.When the migration is scheduled for completion.
  • Рабочая нагрузка замораживается.Workload freezes. Сроки, в течение которых рабочая нагрузка не подлежит изменению.Time frames in which the workload should be ineligible for change.
  • Имя рабочей нагрузки.Workload name.
  • Первоначальный учет.Initial inventory. Любые активы, необходимые для обеспечения функциональности рабочей нагрузки, включая виртуальные машины, IТ-устройства, данные, приложения, конвейеры развертывания и другие.Any assets required to provide the functionality of the workload, including VMs, IT appliances, data, applications, deployment pipelines, and others. Вероятно, эта информация неточная.This information is likely to be inaccurate.

Невыполненная работа по выпуску: согласование бизнес-изменений и техническая координацияRelease backlog: Aligning business change and technical coordination

В контексте миграции выпуск — это действие, которое развертывает одну или несколько рабочих нагрузок в производство.In the context of a migration, a release is an activity that deploys one or more workloads into production. Как правило, выпуск охватывает несколько итераций или технических работ.A release generally covers several iterations or technical work. Однако он представляет собой единую итерацию изменений в бизнесе.However, it represents a single iteration of business change. Выпуск происходит после подготовки одной или нескольких рабочих нагрузок для повышения уровня производства.After one or more workloads have been prepared for production promotion, a release occurs. Решение о упаковке выпуска принимается, когда перенесенные рабочие нагрузки представляют собой достаточную ценность для бизнеса, чтобы оправдать внесение изменений в среду бизнеса.The decision to package a release is made when the workloads migrated represent enough business value to justify injecting change into a business environment. Выпуски выполняются вместе с планом изменений для бизнеса после завершения тестирования деловой деятельности.Releases are executed in conjunction with a business change plan, after business testing has been completed. Команда по разработке стратегии облачных вычислений отвечает за планирование и контроль выпуска, обеспечивая реализацию требуемых бизнес-изменений.The cloud strategy team is responsible for planning and overseeing the execution of a release to ensure that the desired business change is released.

Невыполненная работа по выпуску — это будущий план состояния, который определяет предстоящий выпуск.A release backlog is the future state plan that defines a coming release. Невыполненная работа по выпуску является сводной точкой между управлением изменениями в бизнесе (невыполненная работа по миграции) и управлением техническими изменениями (невыполненная работа по спринту).Release backlog is the pivot point between business change management (migration backlog) and technical change management (sprint backlog). Невыполненная работа по выпуску состоит из списка рабочих нагрузок из невыполненной работы по миграции, которые согласуются с определенным подмножеством реализации результатов деловой деятельности.A release backlog consists of a list of workloads from the migration backlog that align to a specific subset of business outcome realization. Определение и представление невыполненной работы по выпуску в команде по внедрению облачных вычислений служит толчком для более глубокого анализа и планирования миграции.Definition and submission of a release backlog to the cloud adoption team serve as a trigger for deeper analysis and migration planning. Когда команда по внедрению облачных решений проверит технические детали, связанные с выпуском, она сможет принять решение о фиксации выпуска, установив временные рамки выпуска на основе текущих данных.After the cloud adoption team has verified the technical details associated with a release, it can choose to commit to the release, establishing a release timeline based on current knowledge.

Учитывая глубину анализа, выполняемого при проверке выпуска, команда по разработке стратегии облачных решений должна вести список выполнения следующих двух-четырех выпусков.Given the degree of analysis required to validate a release, the cloud strategy team should maintain a running list of the next two to four releases. Перед определением и отправкой выпуска команда должна также попытаться проверить как можно больше следующей информации.The team should also attempt to validate as much of the following information as possible, before defining and submitting a release. Дисциплинированная команда по разработке стратегии облачных решений, способная поддерживать следующие четыре выпуска, может значительно повысить согласованность и точность оценки сроков выпуска.A disciplined cloud strategy team capable of maintaining the next four releases can significantly increase the consistency and accuracy of release timeline estimates.

Точки данных о невыполненной работе по выпускуRelease backlog data points

Сотрудничество между командой по разработке облачной стратегии и командой по внедрению облачных решений позволяет добавить следующие точки данных для любых рабочих нагрузок в невыполненной работе по выпуску:A partnership between the cloud strategy team and the cloud adoption team collaborates to add the following data points for any workloads in the release backlog:

  • Уточненный учет.Refined inventory. Проверка необходимых для миграции активов.Validation of required assets to be migrated. Часто проверяется с помощью журналов или данных мониторинга на уровне узла, сети или уровне ОС для обеспечения точного распознавания сетевых и аппаратных зависимостей каждого актива при стандартной нагрузке.Often validated through log or monitoring data at the host, network, or OS level to ensure an accurate understanding of network and hardware dependencies of each asset under standard load.
  • Шаблоны использования.Usage patterns. Распознавание шаблонов использования пользователями.An understanding of the patterns of usage from end users. Эти модели часто включают анализ географического распределения пользователя, сетевых маршрутов, сезонных всплесков использования, ежедневных/часовых всплесков использования и пользовательский состав (внутренний по сравнению с внешним).These patterns often include an analysis of end-user geographical distribution, network routes, seasonal usage spikes, daily/hourly usage spikes, and end-user composition (interval versus external).
  • Ожидаемые результаты производительности.Performance expectations. Анализ доступных данных журнала пропускной способности, просмотра страниц, сетевых маршрутов и других данных о производительности, необходимых для репликации взаимодействия с конечным пользователем.Analysis of available log data capturing throughput, page views, network routes, and other performance data required to replicate the end-user experience.
  • Сборки.Dependencies. Анализ сетевого трафика и шаблонов использования приложений для выявления любых дополнительных зависимостей рабочей нагрузки, которые должны учитываться при определении последовательности и готовности среды.Analysis of network traffic and application usage patterns to identify any additional workload dependencies, which should be factored into sequencing and environmental readiness. Не включайте рабочую нагрузку в выпуск до тех пор, пока не будет выполнен один из следующих критериев.Don't include a workload in a release until one of the following criteria can be met:
    • Все зависимые рабочие нагрузки были перенесены.All dependent workloads have been migrated.
    • Были реализованы конфигурации сети и безопасности, позволяющие рабочей нагрузке получать доступ ко всем зависимостям в соответствии с существующими ожиданиями производительности.Network and security configurations have been implemented to allow the workload to access all dependencies in alignment with existing performance expectations.
  • Требуемый подход к миграции.Desired migration approach. На уровне невыполненной работы по миграции, предполагаемые трудозатраты по миграции являются единственной рекомендацией, используемой в анализе.At the migration backlog level, the assumed migration effort is the only consideration used in analysis. Например, если результатом деловой деятельности является выход из существующего центра обработки данных, предполагается, что все миграции являются сценарием повторного размещения в невыполненной работе по миграции.For instance, if the business outcome is an exit from an existing datacenter, all migrations are assumed to be a rehost scenario in the migration backlog. В невыполненной работе по выпуску команда по разработке стратегии облачных решений и команда по внедрению облачных решений должны оценить долгосрочную ценность дополнительных функций, модернизации и инвестиций в дальнейшее развитие, чтобы определить, стоит ли использовать более современный подход.In the release backlog, the cloud strategy team and the cloud adoption team should evaluate the long-term value of additional features, modernization, and continued development investments to evaluate whether a more modern approach should be involved.
  • Критерии тестирования бизнеса.Business testing criteria. После того, как рабочая нагрузка будет добавлена к невыполненной работе по миграции, критерии тестирования должны быть взаимно согласованы.After a workload is added to the migration backlog, testing criteria should be mutually agreed on. В некоторых случаях критерии тестирования могут быть ограничены тестированием производительности с определенной группой опытных пользователей.In some cases, testing criteria can be limited to a performance test with a defined power user group. Однако для статистической проверки требуется использовать автоматизированный тест производительности, который должен быть включен в проверку.However, for statistical validation, an automated performance test is desired and should be included. Существующий экземпляр приложения часто не имеет возможности автоматического тестирования.The existing instance of the application often has no automated testing capabilities. Если это доказательство точное, архитекторы облачных решений зачастую работают с опытными пользователями, чтобы создать базовый нагрузочный тест по отношению к существующему решению и установить ориентиры для использования во время миграции.Should this prove accurate, it is not uncommon for the cloud architects to work with power users to create a baseline load test against the existing solution to establish a benchmark to be used during migration.

Частота невыполнения работы по выпускуRelease backlog cadence

В современных миграциях выпуски происходят с регулярной частотой.In mature migrations, releases come in a regular cadence. Скорость работы команды по внедрению облачных решений часто нормализуется для производства выпуска каждые две-четыре итерации (примерно каждые один-два месяца).The velocity of the cloud adoption team often normalizes, producing a release every two to four iterations (approximately every one or two months). Однако это должно быть органическим результатом.However, this should be an organic outcome. Создание искусственных ритмичностей может негативно повлиять на способность группы внедрения облака достичь согласованной пропускной способности.Creating artificial release cadences can negatively affect the cloud adoption team's ability to achieve consistent throughput.

Чтобы стабилизировать влияние на бизнес, команда по разработке стратегии облачных решений должна разработать ежемесячный процесс выпуска с учетом деловой активности для поддержания постоянного диалога, учитывая то, что для прогнозирования частоты регулярного выпуска потребуется несколько месяцев.To stabilize business impact, the cloud strategy team should establish a monthly release process with the business to maintain regular dialogue but should also establish the expectation that it will be several months before a regular release cadence can be predicted.

Невыполненная работа спринта или итерации: согласование технических изменений и усилийSprint or iteration backlog: Aligning technical change and effort

Спринт, или итерация, является последовательной единицей работы, привязанной ко времени.A sprint, or iteration, is a consistent, time-bound unit of work. В процессе миграции она часто измеряется двухнедельным шагом приращения.In the migration process, this is often measured in two-week increments. Однако он не является недоступным для выполнения итераций на одну неделю или четыре недели.However, it's not unheard of to have one-week or four-week iterations. Создание ограниченных по времени итераций требует последовательных интервалов для выполнения трудозатрат и позволяет чаще вносить корректировки в планы на основе новых обучений.Creating time-bound iterations forces consistent intervals of effort completion and allows for more frequent adjustment to plans, based on new learnings. Во время любого спринта обычно выполняются задачи по оценке, миграции и оптимизации рабочих нагрузок, определенных в невыполненной работе по миграциям.During any given sprint, there are usually tasks for the assessment, migration, and optimization of workloads defined in the migration backlog. Эти единицы измерения работы необходимо отслеживать и управлять ими с помощью того же инструмента управления проектами, что используется для невыполненной работы по миграции и выпуску, чтобы обеспечить согласованность на всех уровнях управления изменениями.Those units of work should be tracked and managed in the same project-management tool as the migration and release backlog, to drive consistency across each level of change management.

Невыполненная работа по спринту, или невыполненная работа по итерации, состоит из технической работы, которая должна быть завершена в одном спринте или итерации, которые связанны с миграцией отдельных активов.A sprint backlog, or iteration backlog, consists of the technical work to be completed in a single sprint or iteration, dealing with migrating individual assets. Эту работу необходимо создавать на основе списка перенесенных рабочих нагрузок.That work should be derived from the list of workloads being migrated. При использовании таких средств, как Azure DevOps (ранее Visual Studio Online) для управления проектами, рабочие элементы в спринте будут дочерними элементами элементов невыполненной работы по продукту в невыполненной работе и ситуаций в невыполненной работе по миграции.When using tools like Azure DevOps (previously Visual Studio online) for project management, the work items in a sprint would be children of the product backlog items in a release backlog and the epics in a migration backlog. Такие иерархические отношения обеспечивают ясность на всех уровнях управления изменениями.Such a parent-child relationship allows for clarity at all levels of change management.

В рамках одного спринта или итерации команда по внедрению облачных решений будет работать над тем, чтобы реализовать зафиксированный объем технической работы для выполнения миграции определенной рабочей нагрузки.Within a single sprint or iteration, the cloud adoption team would work to deliver the committed amount of technical work, driving toward the migration of a defined workload. Это конечный результат стратегии управления изменениями.This is the end result of the change management strategy. Когда эти трудозатраты будут завершены, их можно будет протестировать, проверив готовность рабочей нагрузки, размещенной в облаке.When complete, these efforts can be tested by validating production readiness of a workload staged in the cloud.

Большие или сложные структуры спринтаLarge or complex sprint structures

Для небольшой миграции с автономной группой миграции один спринт может включать все четыре этапа миграции для одной рабочей нагрузки (Оценка, Миграция, Оптимизация, безопасность и управление).For a small migration with a self-contained migration team, a single sprint could include all four phases of a migration for a single workload (Assess, Migrate, Optimize, and Secure and manage). Чаще всего, каждый из этих процессов разделяется несколькими командами в различных рабочих элементах между многочисленными спринтами.More commonly, each of these processes shared by multiple teams in distinct work items across numerous sprints. В зависимости от типа, масштаба и ролей трудозатрат, эти спринты могут принимать несколько различных форм.Depending on the effort type, effort scale, and roles, these sprints can take a few different shapes.

  • Фабрика миграций.Migration factory. Крупномасштабные миграции иногда требуют подхода, который напоминает фабрику в модели выполнения.Large-scale migrations sometimes require an approach that resembles a factory in the execution model. В этой модели различным командам выделяется выполнение конкретного процесса миграции (или подмножество процесса).In this model, various teams are allocated to the execution of a specific migration process (or subset of the process). После завершения, спринт выходных данных одной команды заполняет невыполненную работу для следующей команды.After completion, the output of one team's sprint populates the backlog for the next team. Это эффективный подход для крупномасштабного повторного размещения миграций потенциальных рабочих нагрузок, включающий тысячи виртуальных машин, проходящих этапы оценки, архитектуры, исправления и миграции.This is an efficient approach for large-scale rehost migrations of many potential workloads involving thousands of virtual machines moving through phases of assessment, architecture, remediation, and migration. Однако для того чтобы этот подход сработал, необходимо создать новую однородную среду с оптимизированными процессами управления изменениями и утверждениями.However, for this approach to work, a new homogenous environment with streamlined change management and approval processes is a must.
  • Волны миграции.Migration waves. Другим подходом, который хорошо работает для больших миграций, является волновая модель.Another approach that works well for large migrations is a wave model. В этой модели разделение трудозатрат не так уж и ясно.In this model, division of labor isn't nearly as clear. Команды посвящают себя выполнению процесса миграции индивидуальных рабочих нагрузок.Teams dedicate themselves to the migration process execution of individual workloads. Однако характер каждого спринта меняется.However, the nature of each sprint changes. В одном спринте команда может завершить работу по оценке и архитектуре.In one sprint, the team may complete assessment and architecture work. В другом спринте она может завершить миграционную работу.In another sprint, it may complete the migration work. Еще в одном спринте основное внимание будет уделено оптимизации и выпуску продукции.In yet another sprint, the focus would be on optimization and production release. Такой подход позволяет основной команде оставаться согласованной с рабочей нагрузкой и видеть ее во всей полноте на протяжении всего процесса.This approach allows a core team to stay aligned to workloads, seeing them through the process in its entirety. При использовании такого подхода разнообразие навыков и переключение контекста может снизить потенциальную скорость работы команды, замедляя трудозатраты миграции.When using this approach, the diversity of skills and context switching could reduce the potential velocity of the team, slowing the migration effort. Кроме того, препятствий во время этапов утверждения могут приводить к значительным задержкам.Additionally, roadblocks during approval cycles can cause significant delays. Очень важно сохранить параметры в невыполненной работе по выпуску, чтобы помочь команде в продвижении во время заблокированных этапов с этой моделью.It is important to maintain options in the release backlog to keep the team moving during blocked periods, with this model. Также важно перекрестно обучить членов группы и обеспечить соответствие наборов навыков теме каждого спринта.It is also important to cross-train team members and to ensure that skill sets align with the theme of each sprint.

Точки данных невыполненной работы по спринтуSprint backlog data points

Результат спринта фиксирует и документирует изменения, внесенные в рабочую нагрузку, тем самым закрывая цикл управления изменениями.The outcome of a sprint captures and documents the changes made to a workload, thus closing the change-management loop. По завершении необходимо как минимум следующее.When completed, at a minimum, the following should be documented. Во время выполнения спринта, эта документация должна быть заполнена совместно с техническими элементами работ.Throughout the execution of a sprint, this documentation should be completed in tandem with the technical work items.

  • Развернутые активы.Assets deployed. Любые активы, развернутые в облаке для размещения рабочей нагрузки.Any assets deployed to the cloud to host the workload.
  • Исправление.Remediation. Любые изменения в активах для подготовки к миграции в облако.Any changes to the assets to prepare for cloud migration.
  • Настройка.Configuration. Выбор конфигурации всех развернутых активов, включая ссылки на сценарии конфигурации.Chosen configuration of any assets deployed, including any references to configuration scripts.
  • Модель развертывания.Deployment model. Подход, используемый для развертывания актива в облако, включая ссылки на любые сценарии или инструменты развертывания.Approach used to deploy the asset to the cloud, including references to any deployment scripts or tools.
  • AHA.Architecture. Документация архитектуры, развернутой в облаке.Documentation of the architecture deployed to the cloud.
  • Метрики производительности.Performance metrics. Выходные данные автоматизированного тестирования или бизнес-тестирования, выполненного для проверки производительности во время развертывания.Output of automated testing or business testing performed to validate performance at the time of deployment.
  • Уникальные требования или конфигурация.Unique requirements or configuration. Любые уникальные аспекты развертывания, конфигурации или технических требований, необходимые для оперирования рабочей нагрузкой.Any unique aspects of the deployment, configuration, or technical requirements necessary to operate the workload.
  • Утверждение операций.Operational approval. Выход из проверки готовности к работе от владельца приложения и сотрудника ИТ-отдела, ответственного за управление рабочей нагрузкой после развертывания.Sign-off of validating operational readiness from the application owner and the IT operations staff responsible for managing the workload after deployment.
  • Утверждение архитектуры.Architecture approval. Утверждение рабочей нагрузки владельцем и командой по внедрению облачных решений для проверки любых изменений архитектуры, требуемых для размещения каждого актива.Sign-off from the workload owner and the cloud adoption team to validate any architecture changes required to host each asset.

Дальнейшие действияNext steps

После установки подходов к управлению изменениями время, необходимое для устранения окончательного требования, проверки невыполненной работы миграцииAfter change management approaches have been established, its time to address the final prerequisite, migration backlog review