Iteraties en releaseplannen vaststellenEstablish iterations and release plans

Agile en andere iteratieve methoden zijn gebouwd op basis van de concepten van iteraties en releases.Agile and other iterative methodologies are built on the concepts of iterations and releases. In dit artikel vindt u een overzicht van de toewijzing van herhalingen en releases tijdens de planning.This article outlines the assignment of iterations and releases during planning. De toewijzingen van de tijd lijn worden op de zicht baarheid van de gebruikers van het Cloud Strategies team vereenvoudigd.Those assignments drive timeline visibility to make conversations easier among members of the cloud strategy team. De toewijzingen worden ook technische taken uitgelijnd op een manier die het acceptatie team voor de cloud kan beheren tijdens de implementatie.The assignments also align technical tasks in a way that the cloud adoption team can manage during implementation.

Iteraties makenEstablish iterations

In een iteratieve benadering van de technische implementatie plant u technische inspanningen rond terugkerende tijd blokken.In an iterative approach to technical implementation, you plan technical efforts around recurring time blocks. Iteraties zijn vaak een week met een periode van zes weken.Iterations tend to be one-week to six-week time blocks. Consensus adviseert dat twee weken de gemiddelde iteratie duur voor de meeste Cloud acceptatie teams zijn.Consensus suggests that two weeks is the average iteration duration for most cloud adoption teams. Maar de keuze van de iteratie duur is afhankelijk van het type technische inspanning, de administratieve overhead en de voor keur van het team.But the choice of iteration duration depends on the type of technical effort, the administrative overhead, and the team's preference.

Om te beginnen met het uitlijnen van inspanningen op een tijd lijn, wordt u aangeraden een reeks iteraties te definiëren die de laatste zes tot twaalf maanden bedragen.To begin aligning efforts to a timeline, we suggest that you define a set of iterations that last 6 to 12 months.

Meer informatie over VelocityUnderstand velocity

Het uitlijnen van de inspanningen en releases vereist een goed idee van de snelheid.Aligning efforts to iterations and releases requires an understanding of velocity. Snelheid is de hoeveelheid werk die in een bepaalde herhaling kan worden uitgevoerd.Velocity is the amount of work that can be completed in any given iteration. Tijdens de vroege planning is de snelheid een schatting.During early planning, velocity is an estimate. Na enkele herhalingen krijgt de snelheid een zeer waardevolle indicator van de toezeg gingen die het team in vertrouwen kan doen.After several iterations, velocity becomes a highly valuable indicator of the commitments that the team can make confidently.

U kunt de snelheid meten in abstracte termen als artikel punten.You can measure velocity in abstract terms like story points. U kunt deze ook meten in meer concrete voor waarden, zoals uren.You can also measure it in more tangible terms like hours. Voor de meeste iteratieve Frameworks raden we u aan om abstracte metingen te gebruiken om problemen in nauw keurigheid en perceptie te voor komen.For most iterative frameworks, we recommend using abstract measurements to avoid challenges in precision and perception. In de voor beelden in dit artikel wordt de snelheid in uren per Sprint weer gegeven.Examples in this article represent velocity in hours per sprint. Deze representatie maakt het onderwerp universeel duidelijker.This representation makes the topic more universally understood.

Voor beeld: Een Cloud-acceptatie team van vijf personen heeft zich toegezegd aan sprints van twee weken.Example: A five-person cloud adoption team has committed to two-week sprints. Gezien de huidige verplichtingen, zoals vergaderingen en ondersteuning van andere processen, kan elk teamlid 20 uur per week consistent bijdragen aan de acceptatie.Given current obligations like meetings and support of other processes, each team member can consistently contribute 20 hours per week to the adoption effort. Voor dit team is de schatting van de eerste snelheid 100 uur per sprint.For this team, the initial velocity estimate is 100 hours per sprint.

Herhalings planningIteration planning

In eerste instantie plant u iteraties door de technische taken te evalueren op basis van de achterstand met prioriteit.Initially, you plan iterations by evaluating the technical tasks based on the prioritized backlog. Cloud acceptatie teams schatten de inspanningen die nodig zijn om verschillende taken uit te voeren.Cloud adoption teams estimate the effort required to complete various tasks. Deze taken worden vervolgens toegewezen aan de eerste beschik bare iteratie.Those tasks are then assigned to the first available iteration.

Tijdens de herhalings planning worden de schattingen door de acceptatie teams van de Cloud gevalideerd en verfijnd.During iteration planning, the cloud adoption teams validate and refine estimates. Ze doen dit totdat ze alle beschik bare snelheid voor specifieke taken hebben uitgelijnd.They do so until they have aligned all available velocity to specific tasks. Dit proces wordt voortgezet voor elke werk belasting met prioriteit totdat alle inspanningen worden uitgelijnd op een verwachte iteratie.This process continues for each prioritized workload until all efforts align to a forecasted iteration.

In dit proces valideert het team de taken die aan de volgende sprint zijn toegewezen.In this process, the team validates the tasks assigned to the next sprint. Het team werkt de schattingen bij op basis van het gesprek van het team over elke taak.The team updates its estimates based on the team's conversation about each task. Het team voegt elke geschatte taak vervolgens toe aan de volgende sprint totdat aan de beschik bare snelheid wordt voldaan.The team then adds each estimated task to the next sprint until the available velocity is met. Ten slotte schat het team extra taken en voegt deze toe aan de volgende iteratie.Finally, the team estimates additional tasks and adds them to the next iteration. Het team voert deze stappen uit totdat de snelheid van die iteratie ook is uitgeput.The team performs these steps until the velocity of that iteration is also exhausted.

Het voor gaande proces wordt voortgezet totdat alle taken zijn toegewezen aan een herhaling.The preceding process continues until all tasks are assigned to an iteration.

Voor beeld: We gaan nu op het vorige voor beeld bouwen.Example: Let's build on the previous example. Stel dat elke werkbelasting migratie 40 taken vereist.Assume each workload migration requires 40 tasks. Ook wordt ervan uitgegaan dat elke taak een gemiddelde van één uur duurt.Also assume you estimate each task to take an average of one hour. De gecombineerde schatting is ongeveer 40 uur per werkbelasting migratie.The combined estimation is approximately 40 hours per workload migration. Als deze schattingen consistent blijven voor alle 10 van de werk belastingen met prioriteit, zal deze werk belasting 400 uur duren.If these estimates remain consistent for all 10 of the prioritized workloads, those workloads will take 400 hours.

De snelheid die in het vorige voor beeld is gedefinieerd, impliceert dat de migratie van de eerste 10 werk belastingen vier iteraties duurt, die twee maanden na de kalender tijd.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. De eerste iteratie bestaat uit 100 taken die leiden tot de migratie van twee werk belastingen.The first iteration will consist of 100 tasks that result in the migration of two workloads. In de volgende iteratie resulteert een gelijksoortige verzameling van 100-taken in de migratie van drie workloads.In the next iteration, a similar collection of 100 tasks will result in the migration of three workloads.

Waarschuwing

De voor gaande aantallen taken en schattingen worden strikt als voor beeld gebruikt.The preceding numbers of tasks and estimates are strictly used as an example. Technische taken zijn zelden consistent.Technical tasks are seldom that consistent. U ziet dit voor beeld niet als een reflectie van de hoeveelheid tijd die nodig is om een werk belasting te migreren.You shouldn't see this example as a reflection of the amount of time required to migrate a workload.

Release planningRelease planning

In de Cloud-acceptatie wordt een release gedefinieerd als een verzameling van producten die voldoende bedrijfs waarde produceren om het risico van onderbrekingen van bedrijfs processen te rechtvaardigen.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.

Door eventuele wijzigingen in de werk belasting op te heffen in een productie omgeving, worden er enkele wijzigingen aangebracht in de bedrijfs processen.Releasing any workload-related changes into a production environment creates some changes to business processes. In het ideale geval zijn deze wijzigingen naadloos en wordt de waarde van de wijzigingen zonder aanzienlijke onderbrekingen in de service gezien.Ideally, these changes are seamless, and the business sees the value of the changes with no significant disruptions to service. Het risico van bedrijfs onderbreking is echter aanwezig in elke wijziging en mag niet lichter worden genomen.But the risk of business disruption is present with any change and shouldn't be taken lightly.

Om ervoor te zorgen dat een wijziging wordt gerechtvaardigd door de mogelijke rentabiliteit, moet het Cloud strategie team deel nemen aan de release planning.To ensure a change is justified by its potential return, the cloud strategy team should participate in release planning. Zodra taken zijn uitgelijnd op sprints, kan het team een ruwe tijd lijn bepalen wanneer elke werk belasting gereed is voor productie release.Once tasks are aligned to sprints, the team can determine a rough timeline of when each workload will be ready for production release. Het Cloud strategie team bekijkt de timing van elke release.The cloud strategy team would review the timing of each release. Het team identificeert vervolgens het buig punt tussen risico en bedrijfs waarde.The team would then identify the inflection point between risk and business value.

Voor beeld: Als u het vorige voor beeld voortzet, heeft het Cloud strategie team het iteratie plan gecontroleerd.Example: Continuing the previous example, the cloud strategy team has reviewed the iteration plan. De controle heeft twee release punten geïdentificeerd.The review identified two release points. Tijdens de tweede iteratie is een totaal van vijf werk belastingen gereed voor migratie.During the second iteration, a total of five workloads will be ready for migration. Deze vijf werk belastingen bieden een aanzienlijke bedrijfs waarde en activeren de eerste release.Those five workloads will provide significant business value and will trigger the first release. De volgende release komt later twee keer voor wanneer de volgende vijf workloads gereed zijn voor release.The next release will come two iterations later, when the next five workloads are ready for release.

Herhalings paden en tags toewijzenAssign iteration paths and tags

Voor klanten die de acceptatie plannen voor de cloud in azure DevOps beheren, worden de vorige processen weer gegeven door een herhalings pad toe te wijzen aan elke taak en elk gebruikers verhaal.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. We raden ook aan elke workload te coderen met een specifieke versie.We also recommend tagging each workload with a specific release. Deze feed en toewijzing voeren de automatische populatie van tijdlijn rapporten in.That tagging and assignment feed the automatic population of timeline reports.

Volgende stappenNext steps

Schatting maken van tijd lijnen om verwachtingen correct te communiceren.Estimate timelines to properly communicate expectations.