Iteraties en releaseplannen vaststellen

Agile en andere iteratieve methodologieën zijn gebaseerd op de concepten van iteraties en releases. In dit artikel wordt de toewijzing van iteraties en releases tijdens de planning beschreven. Deze toewijzingen stimuleren de zichtbaarheid van de tijdlijn om gesprekken tussen leden van het cloudstrategieteam gemakkelijker te maken. De toewijzingen stemmen ook technische taken af op een manier die het cloudacceptatieteam tijdens de implementatie kan beheren.

Iteraties instellen

In een iteratieve benadering van technische implementatie plant u technische inspanningen rond terugkerende tijdsblokken. Iteraties zijn meestal tijdblokken van één tot zes weken. Consensus suggereert dat twee weken de gemiddelde iteratieduur is voor de meeste teams voor cloudimplementatie. De keuze van de iteratieduur is echter afhankelijk van het type technische inspanning, de administratieve overhead en de voorkeur van het team.

Als u wilt beginnen met het afstemmen van de inspanningen op een tijdlijn, raden we u aan een set iteraties te definiëren die 6 tot 12 maanden duren.

Inzicht in snelheid

Het afstemmen van inspanningen op iteraties en releases vereist inzicht in snelheid. Snelheid is de hoeveelheid werk die kan worden voltooid in een bepaalde iteratie. Tijdens de vroege planning is snelheid een schatting. Na verschillende iteraties wordt snelheid een zeer waardevolle indicator van de toezeggingen die het team met vertrouwen kan doen.

U kunt snelheid meten in abstracte termen, zoals verhaalpunten. U kunt het ook in meer tastbare termen meten, zoals uren. Voor de meeste iteratieve frameworks raden we aan abstracte metingen te gebruiken om uitdagingen in precisie en waarneming te voorkomen. Voorbeelden in dit artikel vertegenwoordigen snelheid in uren per sprint. Deze weergave zorgt ervoor dat het onderwerp meer algemeen wordt begrepen.

Voorbeeld: Een cloudacceptatieteam van vijf personen heeft zich ingezet voor sprints van twee weken. Gezien de huidige verplichtingen zoals vergaderingen en ondersteuning van andere processen, kan elk teamlid consistent 20 uur per week bijdragen aan de implementatie. Voor dit team is de initiële schatting van de snelheid 100 uur per sprint.

Iteratieplanning

In eerste instantie plant u iteraties door de technische taken te evalueren op basis van de achterstall met prioriteit. Teams voor cloudimplementatie schatten de inspanning die nodig is om verschillende taken te voltooien. Deze taken worden vervolgens toegewezen aan de eerste beschikbare iteratie.

Tijdens de iteratieplanning valideren en verfijnen de cloudacceptatieteams schattingen. Ze doen dit totdat ze alle beschikbare snelheid hebben afgestemd op specifieke taken. Dit proces wordt voortgezet voor elke workload met prioriteit totdat alle inspanningen zijn afgestemd op een voorspelde iteratie.

In dit proces valideert het team de taken die zijn toegewezen aan de volgende sprint. Het team werkt de schattingen bij op basis van het gesprek van het team over elke taak. Het team voegt vervolgens elke geschatte taak toe aan de volgende sprint totdat de beschikbare snelheid is bereikt. Ten slotte maakt het team een schatting van extra taken en voegt deze toe aan de volgende iteratie. Het team voert deze stappen uit totdat de snelheid van die iteratie ook is uitgeput.

Het voorgaande proces gaat door totdat alle taken zijn toegewezen aan een iteratie.

Voorbeeld: Laten we verder bouwen op het vorige voorbeeld. Stel dat elke workloadmigratie 40 taken vereist. Ga er ook van uit dat elke taak gemiddeld één uur duurt. De gecombineerde schatting is ongeveer 40 uur per workloadmigratie. Als deze schattingen consistent blijven voor alle 10 workloads met prioriteit, duren deze workloads 400 uur.

De snelheid die in het vorige voorbeeld is gedefinieerd, suggereert dat de migratie van de eerste 10 workloads vier iteraties zal duren, wat twee maanden kalendertijd is. De eerste iteratie bestaat uit 100 taken die resulteren in de migratie van twee workloads. In de volgende iteratie zal een vergelijkbare verzameling van 100 taken resulteren in de migratie van drie workloads.

Waarschuwing

De voorgaande aantallen taken en schattingen worden strikt als voorbeeld gebruikt. Technische taken zijn zelden zo consistent. U ziet dit voorbeeld niet als een weerspiegeling van de hoeveelheid tijd die nodig is om een workload te migreren.

Releaseplanning

Binnen cloudacceptatie wordt een release gedefinieerd als een verzameling producten die voldoende bedrijfswaarde produceren om het risico van onderbreking van bedrijfsprocessen te rechtvaardigen.

Het vrijgeven van eventuele wijzigingen in de werkbelasting in een productieomgeving brengt enkele wijzigingen in bedrijfsprocessen met zich mee. Idealiter zijn deze wijzigingen naadloos en ziet het bedrijf de waarde van de wijzigingen zonder belangrijke serviceonderbrekingen. Maar het risico van bedrijfsonderbreking is aanwezig bij elke wijziging en moet niet licht worden genomen.

Om ervoor te zorgen dat een wijziging wordt gerechtvaardigd door het mogelijke rendement, moet het cloudstrategieteam deelnemen aan de releaseplanning. Zodra taken zijn afgestemd op sprints, kan het team een ruwe tijdlijn bepalen van wanneer elke workload gereed is voor productierelease. Het cloudstrategieteam controleert de timing van elke release. Het team identificeert vervolgens het buigpunt tussen risico en bedrijfswaarde.

Voorbeeld: In het vorige voorbeeld heeft het cloudstrategieteam het iteratieplan beoordeeld. Bij de beoordeling zijn twee releasepunten geïdentificeerd. Tijdens de tweede iteratie zijn in totaal vijf workloads gereed voor migratie. Deze vijf workloads bieden aanzienlijke bedrijfswaarde en activeren de eerste release. De volgende release komt twee iteraties later, wanneer de volgende vijf workloads klaar zijn voor release.

Iteratiepaden en -tags toewijzen

Voor klanten die cloudmigratieplannen beheren in Azure DevOps, worden de vorige processen weerspiegeld door een iteratiepad toe te wijzen aan elke taak en elk gebruikersverhaal. We raden u ook aan elke workload te taggen met een specifieke release. Deze tagging en toewijzing voeden de automatische populatie van tijdlijnrapporten.

Volgende stappen

Maak een schatting van de tijdlijnen om de verwachtingen goed te communiceren.

Tijdlijnen inschatten