Příprava na technickou složitost: agilní Správa změnPrepare for technical complexity: Agile change management

Pokud je možné zrušit a znovu vytvořit celé datové centrum pomocí jednoho řádku kódu, tradiční postupy nedokážou s těmi moderními držet krok.When an entire datacenter can be deprovisioned and re-created with a single line of code, traditional processes struggle to keep up. Pokyny v celém rozhraní pro přijetí do cloudu jsou postavené na postupech, jako je správa IT služeb (ITSM), Open Group Architecture Framework (TOGAF) a dalších.The guidance throughout the Cloud Adoption Framework is built on practices like IT service management (ITSM), the open group architecture framework (TOGAF), and others. Aby byla po provedení obchodních změn zajištěná agilita a rychlost odezvy, tato architektura pracuje s danými postupy tak, aby byly v souladu s agilními metodologiemi a přístupy modelu DevOps.However, to ensure agility and responsiveness to business change, this framework molds those practices to fit agile methodologies and DevOps approaches.

Při přechodu na agilní model, kde jsou zdůrazněna flexibilita a iterace, se Správa technické složitosti a správy změn zpracovává jinak než v tradičním vodopádovém modelu zaměřeném na lineární řadu kroků migrace.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. Tento článek popisuje špičkový přístup ke správě změn v rámci provádění migrace založené na agilních metodách.This article outlines a high-level approach to change management in an agile-based migration effort. Po jeho přečtení byste měli mít obecnou představu o úrovních správy změn a o dokumentaci, která se týká inkrementální migrace.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. Informace, které tady najdete, slouží spolu s doplňujícím školením jako výchozí bod pro výběr a implementaci agilních postupů.Additional training and decisions are required to select and implement agile practices based on that understanding. Účelem tohoto článku je připravit cloudové architekty na diskuzi s projektovými manažery, aby mohli vysvětlit obecný koncept správy změn, který je součástí tohoto přístupu.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.

Řešení technické složitostiAddress technical complexity

Při změně jakéhokoli technického systému vnáší složitost a vzájemná závislost do projektových plánů prvek rizika.When changing any technical system, complexity and interdependency inject risk into project plans. Migrace do cloudu není výjimkou.Cloud migrations are no exception. Při přesunu tisíců (nebo desítky tisíců) prostředků do cloudu se tato rizika připravují.When moving thousands (or tens of thousands) of assets to the cloud, these risks are amplified. Detekce a mapování všech závislostí napříč rozsáhlým digitálním prostředím by trvalo roky.Detecting and mapping all dependencies across a large digital estate could take years. S takto dlouhým analytickým cyklem by se nespokojila snad žádná firma.Few businesses can tolerate such a long analysis cycle. Aby se vyrovnala potřeba analýzy a modernizace podnikové architektury, dokument Architektura přechodu na cloud se v oblasti správy produktových backlogů zaměřuje na model INVEST.To balance the need for architectural analysis and business acceleration, the Cloud Adoption Framework focuses on an INVEST model for product backlog management. Následující části shrnují tento typ modelu.The following sections summarize this type of model.

Model INVEST a sady funkcíINVEST in workloads

Dokument Architektura přechodu na cloud často pracuje s pojmem sada funkcí.The term workload appears throughout the Cloud Adoption Framework. Sada funkcí představuje jednotku aplikačních funkcí, kterou je možné migrovat do cloudu.A workload is a unit of application functionality that can be migrated to the cloud. Může to být jedna aplikace, vrstva aplikace, nebo kolekce aplikací.It could be a single application, a layer of an application, or a collection of an application. Tato definice je flexibilní a v různých fázích migrace se může měnit.The definition is flexible and may change at various phrases of migration. Rozhraní pro přijetí do cloudu používá termín investovat k definování zatížení.The Cloud Adoption Framework uses the term INVEST to define a workload.

INVEST představuje v řadě agilních metodologií běžný akronym pro zápis uživatelských scénářů nebo položek produktových backlogů. Obě tyto položky jsou výstupem nástrojů pro agilní řízení projektů.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. Měrnou jednotkou výstupu migrace je migrovaná sada funkcí.The measurable unit of output in a migration is a migrated workload. Architektura pro přechod do cloudu pracuje s akronymem INVEST trochu volněji a vytváří na jeho základě koncept pro definici sad funkcí:The Cloud Adoption Framework modifies the INVEST acronym a bit to create a construct for defining workloads:

  • Nezávislé: Úlohy by neměly mít žádné nepřístupné závislosti.Independent: A workload should not have any inaccessible dependencies. Aby bylo možné sadu funkcí považovat za migrovanou, všechny závislosti by měly být přístupné a měly by být součástí procesu migrace.For a workload to be considered migrated, all dependencies should be accessible and included in the migration effort.
  • Obchodovatelné: Po provedení dalšího zjišťování se definice úlohy změní.Negotiable: As additional discovery is performed, the definition of a workload changes. Architekti, kteří plánují migraci, můžou měnit faktory týkající se závislostí.The architects planning the migration could negotiate factors regarding dependencies. Mezi body, které můžou podléhat změnám, patří předběžné uvolnění funkcí do produkčního prostředí, zpřístupnění funkcí prostřednictvím hybridní sítě nebo balíčkování všech závislostí do jednoho uvolnění prostředků.Examples of negotiation points could include prerelease of features, making features accessible over a hybrid network, or packaging all dependencies in a single release.
  • Důležité: Hodnota v úloze je měřena možností poskytnout uživatelům přístup k produkčnímu zatížení.Valuable: Value in a workload is measured by the ability to provide users with access to a production workload.
  • Estimable: Všechny závislosti, prostředky, čas migrace, výkon a náklady na Cloud by měly být estimable a měly by být odhadované před migrací.Estimable: Dependencies, assets, migration time, performance, and cloud costs should all be estimable and should be estimated prior to migration.
  • Malé: Cílem je zabalit úlohy v jednom sprintu.Small: The goal is to package workloads in a single sprint. Ne vždy je to ale možné.However, this may not always be feasible. Místo toho se doporučuje plánovat sprinty a uvolnění prostředků tak, aby se co nejvíce zkrátil čas potřebný k přesunu sady funkcí do produkčního prostředí.Instead, teams are encouraged to plan sprints and releases to minimize the time required to move a workload to production.
  • Testovatelné: Vždy by měl být definován způsob testování nebo ověřování dokončení migrace úlohy.Testable: There should always be a defined means of testing or validating completion of the migration of a workload.

Smyslem tohoto akronymu není jeho přísné dodržování. Měl by sloužit jako návod pro definování pojmu sada funkcí.This acronym is not intended as a basis for rigid adherence but should help guide the definition of the term workload.

Backlog migrace: zarovnání obchodních priorit a časováníMigration backlog: Aligning business priorities and timing

Nevyřízené položky migrace umožňují sledovat portfolio úloh nejvyšší úrovně, které se dají migrovat.The migration backlog allows you to track your top-level portfolio of workloads that can be migrated. Před zahájením migrace by tým cloudové strategie a tým přechodu na cloud měly provést kontrolu aktuálního stavu digitálního prostředí a shodnout se na seznamu prioritních sad funkcí, které se budou migrovat.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. Tento seznam bude sloužit jako výchozí backlog migrace.This list forms the basis of the initial migration backlog.

Sady funkcí obsažené v backlogu migrace nebudou na začátku pravděpodobně splňovat kritéria INVEST popsaná v předchozí části.Initially, workloads on the migration backlog are unlikely to meet the INVEST criteria outlined in the previous section. Budou představovat logické seskupení prostředků z počátečního inventáře a bude se od nich odvíjet budoucí práce.Instead, they serve as a logical grouping of assets from an initial inventory as a placeholder for future work. Jako zástupné symboly nemusí být technicky přesné, ale budou sloužit jako základ pro koordinaci postupu s firmou.Those placeholders may not be technically accurate, but they serve as the basis for coordination with the business.

Vztah mezi backlogy migrace, uvolněných prostředků a iterace v průběhu procesu migrace

Backlogy migrace, uvolněných prostředků a iterace zaznamenávají během procesů migrace různé úrovně činností.The migration, release, and iteration backlogs track different levels of activity during migration processes.

V případě všech backlogů migrace by se tým zodpovědný za správu změn měl snažit získat pro všechny sady funkcí, které jsou součástí plánu, následující informace.In any migration backlog, the change management team should strive to obtain the following information for any workload in the plan. Minimálně tato data by měla být k dispozici pro všechny úlohy, které mají prioritu migrace v následujících dvou nebo třech verzích.At a minimum, this data should be available for any workloads prioritized for migration in the next two or three releases.

Informace v backlogu migraceMigration backlog data points

  • Dopad na firmu.Business impact. Je důležité rozumět dopadu, jaký bude mít na firmu případné nesplnění časového plánu nebo používání omezených funkcí v době, kdy budou prostředky zablokované.Understanding of the impact to the business of missing the expected timeline or reducing functionality during freeze windows.
  • Relativní obchodní priority:Relative business priority. Seznam sad funkcí seřazený podle obchodních priorit.A ranked list of workloads based on business priorities.
  • Vlastník firmy.Business owner. Zdokumentujte, kdo zodpovídá za obchodní rozhodnutí související s konkrétní sadou funkcí.Document the one individual responsible for making business decisions regarding this workload.
  • Technický vlastník:Technical owner. Zdokumentujte, kdo zodpovídá za technická rozhodnutí související s touto sadou funkcí.Document the one individual responsible for technical decisions related to this workload.
  • Předpokládaný časový plán:Expected timelines. Doba, na kterou se plánuje dokončení migrace.When the migration is scheduled for completion.
  • Blokování sady funkcí:Workload freezes. Časové rámce, ve kterých by nemělo být možné sadu funkcí změnit.Time frames in which the workload should be ineligible for change.
  • Název úlohy.Workload name.
  • Počáteční inventář:Initial inventory. Všechny prostředky potřebné k tomu, aby sada funkcí pracovala správně, včetně například virtuálních počítačů, IT zařízení, dat, aplikací a kanálů nasazení.Any assets required to provide the functionality of the workload, including VMs, IT appliances, data, applications, deployment pipelines, and others. Tyto informace budou pravděpodobně nepřesné.This information is likely to be inaccurate.

Nevyřízené položky verze: zarovnání firemní změny a technická koordinaceRelease backlog: Aligning business change and technical coordination

V kontextu migrace představuje uvolnění prostředků nasazení jedné nebo několika sad funkcí do produkčního prostředí.In the context of a migration, a release is an activity that deploys one or more workloads into production. Uvolnění prostředků obvykle zahrnuje několik iterací nebo technických kroků.A release generally covers several iterations or technical work. Z pohledu obchodních změn ale představuje jednu iteraci.However, it represents a single iteration of business change. Jakmile bude určený počet sad funkcí připravený pro nasazení v produkčním prostředí, dojde k uvolnění prostředků.After one or more workloads have been prepared for production promotion, a release occurs. Rozhodnutí vytvořit balíček uvolněných prostředků se přijme, pokud migrované sady funkcí mají dostatečnou obchodní hodnotu, která zdůvodní provedení změn v podnikovém prostředí.The decision to package a release is made when the workloads migrated represent enough business value to justify injecting change into a business environment. Uvolnění prostředků probíhá v souladu s plánem obchodních změn a po dokončení firemního testování.Releases are executed in conjunction with a business change plan, after business testing has been completed. Tým cloudové strategie zodpovídá za plánování a dohled nad uvolněním požadovaných podnikových prostředků.The cloud strategy team is responsible for planning and overseeing the execution of a release to ensure that the desired business change is released.

Backlog uvolnění prostředků představuje plán budoucího stavu, který definuje nadcházející uvolnění prostředků.A release backlog is the future state plan that defines a coming release. Backlog uvolnění prostředků je hlavní spojnicí mezi správou obchodních změn (backlog migrace) a správou technických změn (backlog sprintu).Release backlog is the pivot point between business change management (migration backlog) and technical change management (sprint backlog). Backlog uvolnění prostředků tvoří seznam sad funkcí z backlogu migrace, které splňují konkrétní podmnožinu požadavků na výsledné obchodní změny.A release backlog consists of a list of workloads from the migration backlog that align to a specific subset of business outcome realization. Definování a předložení backlogu uvolnění prostředků týmu přechodu na cloud je základem hlubší analýzy a plánování migrace.Definition and submission of a release backlog to the cloud adoption team serve as a trigger for deeper analysis and migration planning. Jakmile tým přechodu na cloud ověří technické údaje související s uvolněním prostředků, může v souladu s aktuálními daty toto uvolnění potvrdit a vytvořit jeho časový plán.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.

V závislosti na stupni analýzy, který je potřeba pro potvrzení uvolnění prostředků, by tým cloudové strategie měl mít vytvořený průběžný seznam následujících dvou až čtyř balíčků s uvolněnými prostředky.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. Před definováním a potvrzením uvolnění prostředků by se tým měl také pokusit ověřit co největší část následujících informací.The team should also attempt to validate as much of the following information as possible, before defining and submitting a release. Pokud je tým cloudové strategie disciplinovaný a dokáže si udržet přehled o následujících čtyřech balíčcích uvolnění prostředků, výrazně se tím zvýší konzistence i přesnost odhadovaných časových rozvrhů těchto uvolnění.A disciplined cloud strategy team capable of maintaining the next four releases can significantly increase the consistency and accuracy of release timeline estimates.

Informace v backlogu uvolnění prostředkůRelease backlog data points

Tým cloudové strategie a tým přechodu na cloud by měly spolupracovat a ke všem sadám funkcí v backlogu uvolnění prostředků přidat následující informace: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:

  • Upřesněný inventář.Refined inventory. Ověření požadovaných prostředků, u kterých proběhne migrace.Validation of required assets to be migrated. Ověření často probíhá pomocí protokolu nebo monitorování dat na úrovni hostitele, sítě nebo operačního systému. Cílem je důkladně se seznámit se závislostmi jednotlivých prostředků na síti a hardwaru při standardním zatížení.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.
  • Vzorce používání.Usage patterns. Pomáhají porozumět tomu, jak koncoví uživatelé pracují s danými prostředky.An understanding of the patterns of usage from end users. Součástí těchto vzorců je často analýza geografického rozmístění koncových uživatelů, síťových tras, pravidelných špiček v provozu, denních a hodinových špiček a složení koncových uživatelů (poměr interních a externích).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).
  • Očekávaný výkon.Performance expectations. Analýza dostupných dat protokolů propustnosti, zobrazení stránek, síťových tras a dalších údajů o výkonu, které jsou nezbytné pro replikaci prostředí koncových uživatelů.Analysis of available log data capturing throughput, page views, network routes, and other performance data required to replicate the end-user experience.
  • Závislosti.Dependencies. Analýza síťového provozu a vzorců pro práci s aplikacemi, která identifikuje všechny doplňující závislosti sady funkcí, které by měly být zohledněny při posuzování připravenosti prostředí.Analysis of network traffic and application usage patterns to identify any additional workload dependencies, which should be factored into sequencing and environmental readiness. Mezi uvolněné prostředky nezahrnujte sadu funkcí, dokud nebudete moct splnit některé z následujících kritérií:Don't include a workload in a release until one of the following criteria can be met:
    • Všechny závislé sady funkcí prošly migrací.All dependent workloads have been migrated.
    • Byly implementovány konfigurace sítě a zabezpečení, které dané sadě funkcí umožňují mít přístup ke všem závislostem tak, aby byly splněny stávající požadavky na výkon.Network and security configurations have been implemented to allow the workload to access all dependencies in alignment with existing performance expectations.
  • Požadovaný postup migrace.Desired migration approach. Na úrovni backlogu migrace představují kroky vedoucí k plánované migraci jen předpoklad, který slouží pro účely analýzy.At the migration backlog level, the assumed migration effort is the only consideration used in analysis. Pokud firma přijme rozhodnutí opustit stávající datové centrum, v backlogu migrace se všechny kroky migrace považují za scénář změny hostování.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. Pomocí backlogu uvolněných prostředků by tým cloudové strategie měl spolu s týmem přechodu na cloud vyhodnotit dlouhodobou hodnotu dalších funkcí, modernizace a nepřetržitých investic do vývoje a rozhodnout o tom, jestli zvolit modernější postup.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.
  • Kritéria firemního testování.Business testing criteria. Jakmile se do backlogu migrace přidá sada funkcí, příslušné týmy by se měly dohodnout na kritériích testování.After a workload is added to the migration backlog, testing criteria should be mutually agreed on. V některých případech mohou být kritéria testování omezena na test výkonnosti s definovanou skupinou Power Users.In some cases, testing criteria can be limited to a performance test with a defined power user group. Pro statistické ověřování se ale vyžaduje automatizovaný test výkonnosti, který by se neměl vynechat.However, for statistical validation, an automated performance test is desired and should be included. Stávající instance aplikace často nemá žádné funkce pro automatizované testování.The existing instance of the application often has no automated testing capabilities. Pokud se tento předpoklad potvrdí, cloudoví architekti obvykle spolupracují se skupinou Power Users, aby pomocí základního zátěžového testu stávajícího řešení vytvořili srovnávací test, který se použije během migrace.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.

Backlog uvolněných prostředků a tempo jejich uvolňováníRelease backlog cadence

Pokud je migrace dobře připravená, prostředky se uvolňují pravidelným tempem.In mature migrations, releases come in a regular cadence. Rychlost práce týmu přechodu na cloud se často ustálí a prostředky se pak uvolňují po každých dvou až čtyřech iteracích (přibližně jednou za měsíc až dva).The velocity of the cloud adoption team often normalizes, producing a release every two to four iterations (approximately every one or two months). Tento proces by se ale neměl zrychlovat na úkor kvality práce.However, this should be an organic outcome. Vytváření tempem umělé verze může negativně ovlivnit schopnost týmu přijetí cloudu dosáhnout konzistentní propustnosti.Creating artificial release cadences can negatively affect the cloud adoption team's ability to achieve consistent throughput.

Aby se stabilizoval dopad na podnik, tým cloudové strategie by měl ve spolupráci s firmou nastavit proces měsíčního uvolňování prostředků a pravidelně s ní komunikovat. Také by měl zajistit, aby si zákazník uvědomoval, že může trvat několik měsíců, než se nastaví pravidelné tempo uvolňování prostředků.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.

Nevyřízené položky sprintu nebo iterace: zarovnání technické změny a úsilíSprint or iteration backlog: Aligning technical change and effort

Sprint neboli iterace představuje konzistentní, časově vázanou jednotku práce.A sprint, or iteration, is a consistent, time-bound unit of work. V procesu migrace se často měří ve dvoutýdenních přírůstcích.In the migration process, this is often measured in two-week increments. Nejedná se však o nevyslechnutí, aby bylo možné mít iterace na týden nebo čtyři týdny.However, it's not unheard of to have one-week or four-week iterations. Vytvoření časově vázaných iterací vynutí pravidelné intervaly pro dokončení dílčích úloh a umožní častěji upravovat plány na základě nově zjištěných informací.Creating time-bound iterations forces consistent intervals of effort completion and allows for more frequent adjustment to plans, based on new learnings. Pro každý sprint jsou obvykle v backlogu migrace definované úlohy týkající se posouzení, migrace a optimalizace sad funkcí.During any given sprint, there are usually tasks for the assessment, migration, and optimization of workloads defined in the migration backlog. Tyto jednotky práce by se měly sledovat a spravovat ve stejném nástroji pro řízení projektů jako backlog migrace a uvolnění prostředků. Tento postup zajistí konzistenci napříč všemi úrovněmi správy změn.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.

Backlog sprintu neboli backlog iterace se skládá z technických úloh, které se mají provést v jednom sprintu nebo iteraci v rámci migrace jednotlivých prostředků.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. Tyto úlohy by měly vycházet ze seznamu sad funkcí, u kterých probíhá migrace.That work should be derived from the list of workloads being migrated. Při používání nástrojů, jako je Azure DevOps (dřív Visual Studio Online) pro řízení projektu, by byly pracovní položky v sprintu podřízenými položkami nevyřízených položek produktu v nevyřízených položkách uvolnění a v náměty v nevyřízených položkách migrace.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. Vztahy nadřazených a podřízených položek zajišťují lepší přehled na všech úrovních správy změn.Such a parent-child relationship allows for clarity at all levels of change management.

Tým přechodu na cloud bude v rámci každého sprintu nebo iterace usilovat o splnění plánovaného množství technických úloh, které budou směřovat k migraci stanovené sady funkcí.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. Toto je konečný výsledek strategie správy změn.This is the end result of the change management strategy. Jakmile bude práce hotová, tým může její úspěšné dokončení otestovat tak, že ověří, jestli je sada funkcí převedená do cloudu připravená pro nasazení v produkčním prostředí.When complete, these efforts can be tested by validating production readiness of a workload staged in the cloud.

Sprinty s rozsáhlou nebo složitou strukturouLarge or complex sprint structures

V případě malé migrace pomocí samostatného migračního týmu může jeden Sprint zahrnovat všechny čtyři fáze migrace pro jednu úlohu (vyhodnocení, migrace, optimalizace a zabezpečení a Správa).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). Častěji se ale stává, že tyto procesy jsou rozdělené do samostatných pracovních položek v různých sprintech a spolupracuje na nich několik týmů.More commonly, each of these processes shared by multiple teams in distinct work items across numerous sprints. V závislosti na typu změn, jejich rozsahu a jednotlivých rolích můžou mít tyto sprinty různou podobu.Depending on the effort type, effort scale, and roles, these sprints can take a few different shapes.

  • Tovární přístup k migraci:Migration factory. Migrace velkého rozsahu někdy vyžaduje přístup, který se v praxi podobá továrně.Large-scale migrations sometimes require an approach that resembles a factory in the execution model. V tomto modelu se různé týmy věnují konkrétnímu procesu migrace (nebo podmnožině procesů).In this model, various teams are allocated to the execution of a specific migration process (or subset of the process). Po jeho dokončení se výstup sprintu jednoho týmu importuje do backlogu pro další tým.After completion, the output of one team's sprint populates the backlog for the next team. Toto je efektivní postup pro migrace velkého rozsahu typu změny hostitele, které zahrnují mnoho sad funkcí a týkají se tisíců virtuálních počítačů, které musí projít posouzením, návrhem architektury, odstraněním problémů a migrací.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. Podmínkou tohoto přístupu je ale nové homogenní prostředí s optimalizovanými procesy pro správu a schvalování změn.However, for this approach to work, a new homogenous environment with streamlined change management and approval processes is a must.
  • Migrace – vlny.Migration waves. Dalším postupem, který se osvědčil u migrací velkého rozsahu, je model vln.Another approach that works well for large migrations is a wave model. V tomto případě není rozdělení práce tak jasné.In this model, division of labor isn't nearly as clear. Týmy se podílí na provádění migrace jednotlivých sad funkcí.Teams dedicate themselves to the migration process execution of individual workloads. Povaha jednotlivých sprintů se ale mění.However, the nature of each sprint changes. V jednom sprintu může určitý tým provést posouzení a vytvořit návrh architektury.In one sprint, the team may complete assessment and architecture work. V jiném sprintu může stejný tým provést samotnou migraci.In another sprint, it may complete the migration work. V následujícím sprintu se může soustředit na optimalizaci a uvolnění prostředků.In yet another sprint, the focus would be on optimization and production release. Tento přístup umožňuje, aby si hlavní tým udržel přehled o sadách funkcí a všech procesech, kterými procházejí.This approach allows a core team to stay aligned to workloads, seeing them through the process in its entirety. Vzhledem k rozmanitosti odborných dovedností a změnám kontextu se může stát, že tým bude pracovat pomaleji a migrace bude trvat déle.When using this approach, the diversity of skills and context switching could reduce the potential velocity of the team, slowing the migration effort. Další významné prostoje můžou být způsobené překážkami, které se objeví během schvalovacích procesů.Additionally, roadblocks during approval cycles can cause significant delays. Při použití tohoto modelu je důležité, aby backlog uvolnění prostředků obsahoval možnosti, díky kterým bude práce postupovat i v době prostojů.It is important to maintain options in the release backlog to keep the team moving during blocked periods, with this model. Je také důležité vymezit členy týmu a zajistit, aby se sady dovedností rovnaly s motivem každého sprintu.It is also important to cross-train team members and to ensure that skill sets align with the theme of each sprint.

Informace v backlogu sprintuSprint backlog data points

Výsledek sprintu zachycuje a dokumentuje změny provedené v sadě funkcí, takže uzavírá smyčku správy změn.The outcome of a sprint captures and documents the changes made to a workload, thus closing the change-management loop. Po dokončení musí být zdokumentovány alespoň následující:When completed, at a minimum, the following should be documented. Během provádění sprintu by tato dokumentace měla být dokončena společně s technickými pracovními položkami.Throughout the execution of a sprint, this documentation should be completed in tandem with the technical work items.

  • Nasazené prostředky:Assets deployed. Všechny prostředky nasazené do cloudu, které hostují zatížení.Any assets deployed to the cloud to host the workload.
  • Nápravné akce:Remediation. Jakékoli změny prostředků, které se mají připravit na migraci do cloudu.Any changes to the assets to prepare for cloud migration.
  • Rozšířeného.Configuration. Vybraná konfigurace všech nasazených prostředků, včetně všech odkazů na konfigurační skripty.Chosen configuration of any assets deployed, including any references to configuration scripts.
  • Model nasazení.Deployment model. Postup, který se použil pro nasazení prostředku do cloudu, včetně odkazů na jakékoli skripty nebo nástroje pro nasazení.Approach used to deploy the asset to the cloud, including references to any deployment scripts or tools.
  • Architektura.Architecture. Dokumentace k architektuře nasazené do cloudu.Documentation of the architecture deployed to the cloud.
  • Metriky výkonu.Performance metrics. Výstup automatizovaného testování nebo podnikového testování prováděného za účelem ověření výkonu v době nasazení.Output of automated testing or business testing performed to validate performance at the time of deployment.
  • Jedinečné požadavky nebo konfigurace:Unique requirements or configuration. Jakékoli jedinečné aspekty nasazení, konfigurace nebo technických požadavků, které jsou nezbytné pro zpracování zatížení.Any unique aspects of the deployment, configuration, or technical requirements necessary to operate the workload.
  • Schválení pro provoz:Operational approval. Odhlášení o ověření provozní připravenosti od vlastníka aplikace a pracovníků IT, kteří zodpovídají za správu zatížení po nasazení.Sign-off of validating operational readiness from the application owner and the IT operations staff responsible for managing the workload after deployment.
  • Schválení architektury:Architecture approval. Vlastník sady funkcí a tým přechodu na cloud potvrdí všechny změny architektury, které jsou potřebné pro hostování jednotlivých prostředků.Sign-off from the workload owner and the cloud adoption team to validate any architecture changes required to host each asset.

Další krokyNext steps

Po navázání přístupů ke správě změn je jeho čas na to, aby vystavil finální požadavek, kontrolu nevyřízených položek migraceAfter change management approaches have been established, its time to address the final prerequisite, migration backlog review