Gantt-diagram til softwareudvikling: en release fra afdækning til evaluering
Planlæg et softwareprojekt som Gantt-diagram: afdækning, design, udvikling, test, udrulning, release og evaluering, med parallelle spor og beslutningsporte, og hvor det passer ved siden af agile sprints.
Et Gantt-diagram for et softwareprojekt viser, hvordan arbejdsspor afhænger af hinanden, og hvornår en release kan lande. Det besvarer et spørgsmål, en sprinttavle ikke gør: hvad er den tidligste dato for releasen, givet afhængighederne?
Kort fortalt
- Planlæg på releaseniveau: spor, porte og afhængigheder, ikke enkelte tickets.
- Parallelle spor vises ved opgaver, der venter på samme forgænger; det længste afgør datoen.
- Beslutningspunkter som omfang aftalt og go/no-go hører til i diagrammet som milepæle.
- Et udviklingsspor kan dimensioneres i sprints omregnet til arbejdsdage.
- Kapacitet og arbejdsindsats modelleres ikke; brug dit sagsstyringsværktøj til dem.
Hvor et Gantt-diagram hjælper et softwareteam, og hvor det ikke gør
De fleste softwareteams kører allerede sprints, og en sprinttavle er det rigtige sted at styre arbejdet i dem. Et Gantt-diagram ligger oven på det. Det dækker hele releasen: hvad der skal være færdigt, før design kan starte, hvilke spor der kan køre parallelt, hvor test skal vente på integration, og hvilke beslutninger der åbner for udrulning. Det er et billede af projektets form, ikke en erstatning for backloggen.
Det, et Gantt-diagram viser, og en tavle ikke gør, er tid og afhængighed sammen. En tavle fortæller, hvad der er i gang. Et Gantt-diagram fortæller, at frontend og backend begge skal være færdige før integration, at test ikke kan starte før da, og at den længste af to parallelle udviklinger bestemmer datoen. Det gør det nyttigt til releaseplanlægning, til samtaler med folk uden for teamet og til at finde det ene spor, der holder alt tilbage.
Hold opgaverne grove. Planlæg på niveau med afdækning, design, udviklingsspor, integration, test, release og evaluering, i arbejdsdage, og lad user stories og tickets blive i dit sagsstyringsværktøj. Arbejder I i sprints, kan et udviklingsspor blot være en opgave, hvis længde er et antal sprints omregnet til arbejdsdage. Prøv ikke at modellere hvert sprints indhold her; diagrammet er forældet i det øjeblik, backloggen flytter sig.
Tilføj beslutningspunkterne som milepæle med længden nul: omfang aftalt, designgennemgang, go eller no-go. Det er dér, en tidsplan reelt afgøres, og når de står i diagrammet, er det svært at springe spørgsmålet over, hvem der beslutter, og hvornår. QueryChart følger ikke arbejdsindsats eller kapacitet, så teamets størrelse modelleres ikke. Eksemplet nedenfor er en komplet releaseplan, trin for trin.
En softwarerelease fra interviews til evaluering efter release
Sytten opgaver. Åbn regnearkspanelet for at se afhængighederne bag hvert trin.
Afdækning ender i en beslutning om omfang
"Interviews med interessenter" (4 arbejdsdage) fører til "Skriv krav" (5). "Omfang aftalt" er en milepæl med længden 0, og begge designspor venter på den.
To designspor, én gennemgang
"Teknisk arkitektur" (4 arbejdsdage) og "UX-design og prototype" (8) starter begge efter "Omfang aftalt". "Designgennemgang" venter på begge, så UX-arbejdet, som det længste spor, afgør, hvornår den finder sted.
Udviklingsspor og testforberedelse
"Backend-udvikling" (20 arbejdsdage) og "Frontend-udvikling" (18) starter efter "Designgennemgang" og mødes ved "Integration" (5). "Testplan og testdata" (4) starter også efter gennemgangen, så den er klar længe før, testen skal bruge den.
Test, beslut, udrul, evaluér
"Systemtest" venter på "Integration" og testforberedelsen. "Go/no-go-beslutning" er en milepæl før "Udrul til produktion" (2 arbejdsdage), derefter "Release", "Intensiv support" (10) og "Evaluering efter release" (2).
Sådan fungerer det
Beslut detaljeringsniveauet
Planlæg på releaseniveau. Hver opgave bør være et spor eller en fase, der tager dage eller uger, ikke en ticket. Er en opgave kortere end et par dage, så læg den ind under sin overordnede.
Indtast afdækning og design med beslutningsmilepælene
Tilføj afdækning- og designopgaver med længder i arbejdsdage, og tilføj milepæle med længden nul for omfang aftalt og designgennemgang. Lad næste fase afhænge af milepælen, ikke af den sidste opgave.
Sæt parallelle spor på samme forgænger
Backend, frontend og testforberedelse bør alle afhænge af designgennemgangen. Kæd dem ikke efter hinanden; diagrammets pointe er at vise, hvad der kan overlappe.
Omregn sprints til arbejdsdage
Tager et spor fire sprints på to uger, så skriv 40 arbejdsdage. Tilføj kun forskydning, hvor der er en reel ventetid, som et release freeze.
Tilføj releaseportene
Tilføj go/no-go som en milepæl før udrulning, og giv intensiv support og evalueringen efter release hver sin opgave, så planen dækker ugerne efter lanceringen.
Fremhæv den kritiske vej, og del
Slå Vis ▸ Kritisk vej til for at se kæden, der bestemmer releasedatoen, og del derefter diagrammet som link eller eksportér en PDF til interessenterne.
Faldgruber du skal undgå
At planlægge på ticketniveau
Et Gantt-diagram med hundredvis af små opgaver er forældet inden for et sprint. Hold det på sporniveau og lad sagsstyringsværktøjet rumme detaljerne.
At kæde parallelle spor
At sætte frontend efter backend, fordi én person laver begge dele, skjuler den reelle afhængighedsstruktur. Forbind opgaver efter det, de virkelig har brug for, og notér delte personer i feltet Personer (People).
At glemme, at kapacitet ikke modelleres
To opgaver givet til samme person kan overlappe uden varsel. QueryChart registrerer ansvarlige, men tjekker ikke arbejdsbelastning.
At udelade ugerne efter release
Intensiv support og en evaluering er rigtigt arbejde. Udelades de, slutter planen på releasedagen, hvilket sjældent er dagen, hvor teamet er ledigt.
Åbn softwareprojekt-skabelonen
Åbn softwareprojektplanen som dit eget diagram, udskift sporene med dine egne og del releasetidslinjen.
Relaterede guides
Ofte stillede spørgsmål
Passer et Gantt-diagram til et agilt team?
Ja, på releaseniveau. Brug det til projektets form, dets afhængigheder og porte, og hold sprintens indhold i dit backlogværktøj. De to besvarer forskellige spørgsmål.
Hvad viser et Gantt-diagram, som en tavle ikke gør?
Tid og afhængighed sammen: hvilke spor der kører parallelt, hvilke der skal være færdige, før det næste kan starte, og hvilken kæde der bestemmer releasedatoen.
Hvordan planlægger jeg et sprint i diagrammet?
Det gør du som regel ikke. Udtryk et udviklingsspor som en opgave, hvis længde er dets antal sprints i arbejdsdage, og lad sprintens indhold ligge på tavlen.
Kan jeg koble det til mit sagsstyringsværktøj?
Nej. QueryChart har ingen integrationer med sagsstyringsværktøjer. Du kan indsætte rækker fra en regnearkseksport i regnearket.
Kan jeg vise, hvem der arbejder på hvad?
Ja, hver opgave har et felt Personer (People). Der er ingen kontrol af arbejdsbelastning eller overbelastning.
