Etablera iterationer och publiceringsplanerEstablish iterations and release plans

Agile och andra iterativa metoder bygger på begreppen iterationer och versioner.Agile and other iterative methodologies are built on the concepts of iterations and releases. Den här artikeln beskriver tilldelningen av iterationer och versioner under planeringen.This article outlines the assignment of iterations and releases during planning. De här tilldelningarna driver tids linje synlighet för att göra konversationer enklare bland medlemmarna i moln strategi teamet.Those assignments drive timeline visibility to make conversations easier among members of the cloud strategy team. Tilldelningarna justerar också tekniska uppgifter på ett sätt som moln implementerings teamet kan hantera under implementeringen.The assignments also align technical tasks in a way that the cloud adoption team can manage during implementation.

Upprätta iterationerEstablish iterations

I en iterativ metod för teknisk implementering planerar du tekniska ansträngningar kring återkommande tids block.In an iterative approach to technical implementation, you plan technical efforts around recurring time blocks. Iterationer tenderar att vara en vecka till sex veckors tids block.Iterations tend to be one-week to six-week time blocks. Konsensus rekommenderar att två veckor är den genomsnittliga upprepnings tiden för de flesta moln implementerings team.Consensus suggests that two weeks is the average iteration duration for most cloud adoption teams. Valet av upprepnings tid beror på typen av teknisk ansträngning, den administrativa belastningen och teamets preferens.But the choice of iteration duration depends on the type of technical effort, the administrative overhead, and the team's preference.

Om du vill börja justera ansträngningarna på en tids linje, rekommenderar vi att du definierar en uppsättning iterationer som de senaste 6 till 12 månaderna.To begin aligning efforts to a timeline, we suggest that you define a set of iterations that last 6 to 12 months.

Förstå hastighetUnderstand velocity

Anpassning av insatser till iterationer och versioner kräver en förståelse av hastigheten.Aligning efforts to iterations and releases requires an understanding of velocity. Hastighet är den mängd arbete som kan slutföras i en bestämd iteration.Velocity is the amount of work that can be completed in any given iteration. Vid tidig planering är hastigheten en uppskattning.During early planning, velocity is an estimate. Efter flera iterationer blir hastigheten en mycket värdefull indikator för de åtaganden som teamet kan göra på ett säkert sätt.After several iterations, velocity becomes a highly valuable indicator of the commitments that the team can make confidently.

Du kan mäta hastigheten i abstrakta termer som artikel punkter.You can measure velocity in abstract terms like story points. Du kan också mäta den i mer konkreta termer som timmar.You can also measure it in more tangible terms like hours. För de flesta iterativa ramverk rekommenderar vi att du använder abstrakta mätningar för att undvika utmaningar i precision och uppfattning.For most iterative frameworks, we recommend using abstract measurements to avoid challenges in precision and perception. Exemplen i den här artikeln representerar hastighet i timmar per Sprint.Examples in this article represent velocity in hours per sprint. Den här presentationen gör ämnet mer allmänt förstått.This representation makes the topic more universally understood.

Exempel: Ett moln antagande team med fem personer har allokerats till två veckors sprintar.Example: A five-person cloud adoption team has committed to two-week sprints. Med tanke på aktuella skyldigheter som möten och stöd för andra processer kan varje grupp medlem konsekvent bidra med 20 timmar per vecka till implementerings ansträngningen.Given current obligations like meetings and support of other processes, each team member can consistently contribute 20 hours per week to the adoption effort. För det här teamet är den inledande hastighets uppskattningen 100 timmar per Sprint.For this team, the initial velocity estimate is 100 hours per sprint.

Upprepnings planeringIteration planning

Börja med att planera iterationer genom att utvärdera de tekniska uppgifterna baserat på den prioriterade efter släparna.Initially, you plan iterations by evaluating the technical tasks based on the prioritized backlog. Moln implementerings team uppskattar den insats som krävs för att slutföra olika uppgifter.Cloud adoption teams estimate the effort required to complete various tasks. Dessa uppgifter tilldelas sedan till den första tillgängliga iterationen.Those tasks are then assigned to the first available iteration.

Under upprepnings planeringen bör moln implementerings teamen validera och förfina uppskattningar.During iteration planning, the cloud adoption teams validate and refine estimates. De gör det tills de har justerat all tillgänglig hastighet för vissa aktiviteter.They do so until they have aligned all available velocity to specific tasks. Den här processen fortsätter för varje prioriterad arbets belastning tills alla ansträngningar justeras till en prognostiserad iteration.This process continues for each prioritized workload until all efforts align to a forecasted iteration.

I den här processen validerar teamet de uppgifter som tilldelats nästa Sprint.In this process, the team validates the tasks assigned to the next sprint. Gruppen uppdaterar sina uppskattningar baserat på teamets konversation om varje uppgift.The team updates its estimates based on the team's conversation about each task. Teamet lägger sedan till varje uppskattad aktivitet till nästa Sprint tills den tillgängliga hastigheten är uppfylld.The team then adds each estimated task to the next sprint until the available velocity is met. Slutligen beräknar teamet ytterligare aktiviteter och lägger till dem i nästa iteration.Finally, the team estimates additional tasks and adds them to the next iteration. Teamet utför dessa steg tills hastigheten för den iterationen också är slut.The team performs these steps until the velocity of that iteration is also exhausted.

Föregående process fortsätter tills alla aktiviteter har tilldelats en iteration.The preceding process continues until all tasks are assigned to an iteration.

Exempel: Vi bygger på föregående exempel.Example: Let's build on the previous example. Antag att varje arbets belastnings migrering kräver 40-aktiviteter.Assume each workload migration requires 40 tasks. Anta också att du uppskattar varje aktivitet för att ta ett genomsnitt på en timme.Also assume you estimate each task to take an average of one hour. Den kombinerade uppskattningen är cirka 40 timmar per migrering av arbets belastning.The combined estimation is approximately 40 hours per workload migration. Om dessa uppskattningar är konsekventa för alla tio av de prioriterade arbets belastningarna tar de här arbets belastningarna att ta 400 timmar.If these estimates remain consistent for all 10 of the prioritized workloads, those workloads will take 400 hours.

Den hastighet som definieras i föregående exempel innebär att migreringen av de första 10 arbets belastningarna tar fyra iterationer, vilket är två månader från kalender tiden.The velocity defined in the previous example suggests that the migration of the first 10 workloads will take four iterations, which is two months of calendar time. Den första iterationen kommer att bestå av 100 uppgifter som resulterar i migreringen av två arbets belastningar.The first iteration will consist of 100 tasks that result in the migration of two workloads. I nästa iteration leder en liknande samling med 100 uppgifter till migreringen av tre arbets belastningar.In the next iteration, a similar collection of 100 tasks will result in the migration of three workloads.

Varning

Föregående antal aktiviteter och uppskattningar används strikt som exempel.The preceding numbers of tasks and estimates are strictly used as an example. De tekniska uppgifterna är sällan som konsekventa.Technical tasks are seldom that consistent. Du bör inte se det här exemplet som en reflektion av hur lång tid det tar att migrera en arbets belastning.You shouldn't see this example as a reflection of the amount of time required to migrate a workload.

Versions planeringRelease planning

I molnet definieras en version som en samling slut produkter som producerar tillräckligt med affärs värde för att motivera risken för avbrott i affärs processerna.Within cloud adoption, a release is defined as a collection of deliverables that produce enough business value to justify the risk of disruption to business processes.

Om du släpper alla arbets belastnings ändringar i en produktions miljö skapas vissa ändringar i affärs processerna.Releasing any workload-related changes into a production environment creates some changes to business processes. Vi rekommenderar att dessa ändringar är sömlösa och att företaget ser värdet av ändringarna utan betydande avbrott i tjänsten.Ideally, these changes are seamless, and the business sees the value of the changes with no significant disruptions to service. Men risken för affärs avbrott finns i alla förändringar och bör inte beaktas lätt.But the risk of business disruption is present with any change and shouldn't be taken lightly.

För att säkerställa att en ändring är motiverad av den potentiella avkastningen bör moln strategi teamet delta i versions planering.To ensure a change is justified by its potential return, the cloud strategy team should participate in release planning. När aktiviteter har justerats till Sprint, kan teamet fastställa en grov tids linje för när varje arbets belastning blir redo för produktions versionen.Once tasks are aligned to sprints, the team can determine a rough timeline of when each workload will be ready for production release. Moln strategi teamet granskar tiden för varje version.The cloud strategy team would review the timing of each release. Teamet identifierar sedan Bryt-punkten mellan risk-och affärs värde.The team would then identify the inflection point between risk and business value.

Exempel: Genom att fortsätta med föregående exempel har moln strategi teamet granskat upprepnings planen.Example: Continuing the previous example, the cloud strategy team has reviewed the iteration plan. Granskningen identifierade två lanserings punkter.The review identified two release points. Under den andra iterationen är totalt fem arbets belastningar redo för migrering.During the second iteration, a total of five workloads will be ready for migration. De fem arbets belastningarna ger betydande affärs värde och kommer att utlösa den första versionen.Those five workloads will provide significant business value and will trigger the first release. Nästa version kommer att få två iterationer senare, när de följande fem arbets belastningarna är klara att lanseras.The next release will come two iterations later, when the next five workloads are ready for release.

Tilldela upprepnings banor och TaggarAssign iteration paths and tags

För kunder som hanterar moln implementerings planer i Azure DevOps visas tidigare processer genom att tilldela en upprepnings väg till varje aktivitet och användar berättelse.For customers who manage cloud adoption plans in Azure DevOps, the previous processes are reflected by assigning an iteration path to each task and user story. Vi rekommenderar även att tagga varje arbets belastning med en angiven version.We also recommend tagging each workload with a specific release. Den taggade och tilldelningen matar in den automatiska populationen av tids linje rapporter.That tagging and assignment feed the automatic population of timeline reports.

Nästa stegNext steps

Uppskatta tids linjer för att kommunicera förväntningarna på rätt sätt.Estimate timelines to properly communicate expectations.