Správa změn v průběhu přírůstkové migraceManage change in an incremental migration effort

V tomto článku se předpokládá, že procesy migrace jsou z povahy věcí přírůstkové a běží paralelně s procesem řízení.This article assumes that migration processes are incremental in nature, running parallel to the govern process. Stejné pokyny se ale můžou použít k naplnění počátečních úkolů ve struktuře členění práce pro účely tradičního kaskádového řízení změn.However, the same guidance could be used to populate initial tasks in a work breakdown structure for traditional waterfall change management approaches.

Backlog vydáníRelease backlog

Backlog vydání se skládá z řady prostředků (mimo jiné virtuálních počítačů, databází, souborů a aplikací), které se musí migrovat předtím, než se úloha uvolní pro produkční využití v cloudu.A release backlog consists of a series of assets (VMs, databases, files, and applications, among others) that must be migrated before a workload can be released for production usage in the cloud. Během každé iterace tým přechodu na cloud zdokumentuje a odhadne úsilí potřebné k přesunu jednotlivých prostředků do cloudu.During each iteration, the cloud adoption team documents and estimates the efforts required to move each asset to the cloud. Podívejte se na část "backlog iterace", která následuje.See the "iteration backlog" section that follows.

Backlog iteraceIteration backlog

Backlog iterace je podrobný seznam prací, které jsou potřeba k migraci určitého počtu prostředků ze stávajícího digitálního aktiva do cloudu.An iteration backlog is a list of the detailed work required to migrate a specific number of assets from the existing digital estate to the cloud. Položky tohoto seznamu jsou často uložené jako pracovní položky v agilním nástroji pro správu, jako je Azure DevOps.The entries on this list are often stored in an agile management tool, like Azure DevOps, as work items.

Před zahájením první iterace určí tým přechodu na cloud dobu trvání iterace, která je obvykle od dvou do čtyř týdnů.Prior to starting the first iteration, the cloud adoption team specifies an iteration duration, usually two to four weeks. Tento časový úsek je důležitý k vytvoření počátečního a koncového období pro každou sadu potvrzených aktivit.This time box is important to create a start and finish time period for each set of committed activities. Udržování konzistentních spouštěcích oken usnadňuje měření rychlosti (tempa migrace) a přizpůsobení měnícím se obchodním potřebám.Maintaining consistent execution windows makes it easy to gauge velocity (pace of migration) and alignment to changing business needs.

Před každou iterací tým kontroluje backlog vydání a odhadne úsilí a priority prostředků, které se mají migrovat.Prior to each iteration, the team reviews the release backlog, estimating the effort and priorities of assets to be migrated. Pak potvrdí doručení určitého počtu dohodnutých migrací.It then commits to deliver a specific number of agreed-on migrations. Po schválení týmem přechodu na cloud se seznam aktivit stane aktuálním backlogem iterace.After this is agreed to by the cloud adoption team, the list of activities becomes the current iteration backlog.

Během každé iterace členové týmu pracují jako samoorganizovaný tým, který plní závazky v rámci aktuálního backlogu iterace.During each iteration, team members work as a self-organizing team to fulfill commitments in the current iteration backlog.

Další krokyNext steps

Jakmile se backlog iterace definuje a přijme týmem přechodu na cloud, je možné dokončit schválení správy změn.After an iteration backlog is defined and accepted by the cloud adoption team, change management approvals can be finalized.