Sådan planlægger du en softwareudgivelse i et Gantt-diagram
Planlæg strækningen fra færdige funktioner til produktion: gør kodefrysen til en milepæl, kør testspor parallelt, saml dem før godkendelsen, og aflæs den kritiske vej for at se, hvad der afgør udgivelsesdatoen.
Udgivelsesdatoer bliver som regel meldt ud, før testplanen findes. Guiden viser, hvordan du gør strækningen fra frys til produktion til en tidsplan, du kan kontrollere mod den dato, du har fået.
Kort fortalt
- Gør kodefrysen til en milepæl med længden 0, som alle udviklingsopgaver skal nå.
- Start testspor, udgivelsesnoter og driftsvejledning fra frysen, så de kører side om side.
- Saml alle spor i én opgave før godkendelsen, og lad derefter udrulningen afhænge af godkendelsen og dokumenterne.
- Planlæg dagene efter udrulningen som opgaver: en smoke-test, en offentliggørelse og et overvågningsvindue.
- Slå den kritiske vej til for at se, hvilket spor der afgør datoen, og sammenlign slutdatoen med den dato, du skal bruge.
Planlæg strækningen efter den sidste funktion
En udgivelsesplan er kort, men tæt. Sytten opgaver kan rummes på omkring en måned, og de fleste afhænger af to eller tre andre. Det er derfor, en flad tjekliste svigter her: den fortæller, hvad der skal ske, men ikke at brugeraccepttesten kan starte to dage efter frysen, mens regressionstesten ikke kan slutte før den, eller at driftsvejledningen skal være klar den dag, udrulningen starter, ikke den dag, testen slutter.
Metoden er at planlægge i fire træk. Først gør du frysen til en milepæl, som alt før den skal nå. For det andet starter du testsporene fra frysen og lader dokumentationen starte der også. For det tredje samler du sporene i én opgave før godkendelsen, så godkendelsen ikke kan dukke op for tidligt. For det fjerde giver du udrulningen dens porte og planlægger dagene efter den som rigtige opgaver. Datoer beregnes så ud fra længder og links, og du sammenligner slutdatoen med den dato, du skal bruge, i stedet for at skrive datoen ind først.
En tidsplan gør ikke en udgivelse sikker. Den viser, hvornår arbejdet burde være færdigt, hvis hvert estimat holder, og den opdager hverken en manglende test eller en rollback, der ikke er afprøvet. Hold testresultater, godkendelser og fejllisten i de systemer, der rummer dem. Diagrammet planlægger rækkefølge og tid og er ikke forbundet til et repository, et ticketsystem eller et udrulningsværktøj.
Eksemplet er skabelonen for softwareudgivelse på /da/templates/gantt-diagram-til-softwareudgivelse. Har du brug for processen og dens beslutninger frem for tidsplanen, se flowdiagrammerne på /da/templates/software-release-proces og /da/templates/software-deployment-proces. Til et helt forløb, fra krav til lancering, brug /da/templates/software-projekt-gantt-diagram.
En udgivelsesplan, bygget i trin
Sytten opgaver fordelt på fire grupper. Varighederne er eksempler i arbejdsdage; sæt dine egne. Åbn regnearkspanelet for at se rækkerne bag hvert trin.
Udviklingen ender i en milepæl
"Færdiggør resterende funktioner" er 10 arbejdsdage. "Ret kendte fejl" (6 dage) starter 5 arbejdsdage efter, at den er startet, et start-til-start-link med forsinkelse, så fejlrettelsen overlapper udviklingens slutning. "Funktioner færdige" er en milepæl med længden 0.
Frysen og tre testspor
"Kodefrys" er en milepæl. "Regressionstest" (5 dage), "Ydelses- og sikkerhedstjek" (4) og "Brugeraccepttest" (6) følger alle efter den, og accepttesten starter 2 arbejdsdage efter frysen. "Ret udgivelsesblokerende fejl" (3 dage) venter på alle tre.
Forberedelse og udrulningsporte
"Skriv udgivelsesnoter" og "Opdater driftsvejledning og rollback-plan" (3 dage hver) starter ved frysen, ikke efter testen. "Udrul til produktion" (1 dag) venter på "Godkendelse af udgivelse", noterne og driftsvejledningen. "Smoke-test i produktion" følger efter.
Dagene efter udrulningen
"Offentliggør udgivelsen" (1 dag) og "Overvåg og håndter tidlige problemer" (5 dage) venter begge på smoke-testen, så de kører side om side. "Retrospektiv på udgivelsen" er den sidste opgave, en dag til det, den næste plan bør ændre.
Sådan fungerer det
List opgaverne mellem den sidste funktion og den første bruger
Skriv hver opgave, der skal være færdig før og efter produktion, også dokumenter og rollback-planen. Giv hver en længde i arbejdsdage. Kun hele dage, så rund en halv dags opgave op.
Sæt frysen som en milepæl
Tilføj en opgave med længden 0 til frysen. Lad den afhænge af udviklingsopgaverne, og lad testsporene, udgivelsesnoterne og driftsvejledningen afhænge af den.
Overlap det, der kan overlappe
Brug et start-til-start-link med forsinkelse, hvor arbejdet begynder et stykke inde i en anden opgave, for eksempel 4SS+2 i kolonnen for afhængigheder. Brug det til fejlrettelse under udviklingen og til accepttest, der starter nogle dage efter frysen.
Saml sporene før godkendelsen
Giv opgaven efter testen en afhængighed af hvert spor, skrevet som en kommasepareret liste. Godkendelsen kan så ikke ligge før det langsomste spor.
Giv udrulningen porte, og planlæg dagene efter den
Lad udrulningen afhænge af godkendelsen og dokumenterne. Tilføj en smoke-test, offentliggørelsen og et overvågningsvindue som opgaver, så supporttid er en del af planen.
Tjek den kritiske vej mod din dato
Åbn menuen Visning, og slå den kritiske vej til. Sammenlign slutdatoen med den dato, du skal bruge. Er datoen fast, så ændr den kæde, der afgør den, for at forkorte andre opgaver flytter den ikke.
Faldgruber du skal undgå
At skrive dokumenter efter testen
Udgivelsesnoter og en rollback-plan, der skrives efter testen, lægger deres længde oveni planens slutning. Start dem ved frysen, og lad udrulningen vente på dem, så de ikke springes over under tidspres.
Godkendelse uden samling
Hvis godkendelsen kun afhænger af ét testspor, viser diagrammet en dato, de andre spor måske ikke når. Forbind den, direkte eller gennem en rettelsesopgave, til alle spor.
At glemme dagene efter udrulningen
En plan, der slutter ved udrulningen, skjuler overvågningen og rettelserne, der følger. Behold et overvågningsvindue i diagrammet, selv om dets længde er et gæt.
At binde udgivelsesdatoen som en start
En fast start på udrulningsopgaven får ikke det tidligere arbejde til at passe. Er den beregnede dato senere end den bundne, markerer diagrammet konflikten. Læs markeringen som beskeden om, at datoen ikke kan nås med disse estimater.
Åbn Gantt-diagrammet for softwareudgivelse
Åbn udgivelsesskabelonen, ret varighederne til dine egne, og se, hvilket testspor der afgør datoen.
Relaterede guides
Ofte stillede spørgsmål
Hvor lang bør en udgivelsesplan være?
Så lang, som arbejdet mellem frysen og produktion tager på dit hold. Skabelonens længder er eksempler. Erstat dem med, hvad dine seneste udgivelser tog, og tag dagene efter udrulningen med.
Skal frysen være en opgave eller en milepæl?
En milepæl, som er en opgave med længden 0 og tegnes som en diamant. Den markerer det punkt, alt før den skal nå, og testsporene er forbundet til den.
Kan jeg se, hvilket testspor der afgør udgivelsesdatoen?
Ja. Slå den kritiske vej til i menuen Visning. Den lyser den kæde af opgaver op, der afgør slutningen, og vælger du en opgave, lyser den det, den afhænger af, og det, der afhænger af den.
Virker det med hotfixes?
En hotfix er et kort diagram: ret, test, godkend, udrul, smoke-test. Duplikér et udgivelsesdiagram, fjern det, du ikke har brug for, og behold portene.
Hvor er selve udgivelsesprocessen?
I flowdiagramskabelonerne, som tegner beslutninger og godkendelser: /da/templates/software-release-proces og /da/templates/software-deployment-proces. Brug Gantt-diagrammet til, hvor lang tid det tager, og flowdiagrammet til, hvem der beslutter hvad.
