Et team på fem udviklere har brug for fire faste rutiner: kodegennemgang, automatisk test, en gentagelig release og opfølgning, når noget går galt. Med dem på plads kan I lægge mere på teamet, uden at kvaliteten afhænger af, hvem der er på arbejde den dag. Resten af det, der ofte kaldes proces, kan vente, til I mærker et konkret problem.
Artiklen er skrevet til stifteren eller direktøren, der skal kunne spørge ind til rutinerne. Teamet vælger selv værktøjerne.
Hvad processen skal gøre for jer
Så længe to udviklere sidder sammen, klarer de meget ved at tale om det. Ved fem udviklere rører flere ved samme kode, og ingen kan følge med i alt. Processen skal derfor løse tre ting. Fejl skal fanges, før kunderne ser dem. Viden om koden skal fordeles på flere personer. Og en ændring skal kunne komme ud til kunderne, uden at én bestemt person skal være til stede.
Spørg efter de tre virkninger, når teamet foreslår en ny rutine. En rutine, der ikke hjælper på nogen af dem, kan I roligt springe over.
De fire rutiner
Kodegennemgang. Inden en ændring kommer ind i det fælles produkt, læser en anden udvikler den. På engelsk hedder det code review. Gevinsten ligger lige så meget i, at to personer nu kender ændringen, som i de fejl, der bliver fundet. Aftal, at al kode gennemgås af en anden end forfatteren, også kode fra lead developeren, altså den mest erfarne, som styrer teamets tekniske arbejde.
Automatisk test. Når en udvikler lægger en ændring op, kører en maskine et sæt test og melder tilbage, om noget er gået i stykker. Det kaldes ofte CI, continuous integration. I behøver ikke test af det hele fra første dag. Begynd med det, der koster dyrest, hvis det fejler: login, betaling og de få handlinger, kunderne bruger hver dag.
Release. En release er det øjeblik, hvor ændringerne kommer ud til kunderne. Den skal kunne gennemføres af flere personer med samme fremgangsmåde, helst med et enkelt tryk, og den skal kunne rulles tilbage. Automatikken kaldes CD, continuous delivery. Har I kun én, der tør lave en release, er det den rutine, I skal tage først. Mere om, hvorfor små og hyppige udgivelser er tryggere, står i hver release er en risiko.
Opfølgning på fejl. Når noget er gået galt i drift, sætter teamet sig kort sammen dagen efter og skriver tre ting ned: hvad skete, hvorfor opdagede vi det sent, og hvad ændrer vi. Fokus ligger på systemet og aldrig på den, der trykkede på knappen. Sådan en evaluering er beskrevet i produktet var nede.
Når kodegennemgangene hober sig op
Det mest almindelige problem i et lille team er køen. Ændringerne ligger og venter, fordi alle hellere vil skrive kode end læse andres, eller fordi kun én person må godkende. Udviklerne starter imens på noget nyt, og så har I fem halvfærdige opgaver i stedet for to færdige.
Tre aftaler løser det meste:
- Små ændringer. En ændring, der kan læses på et kvarter, bliver gennemgået samme dag. Store ændringer bliver liggende.
- En fast svartid. Aftal, at en ændring får sit første svar samme arbejdsdag eller senest næste morgen.
- Flere, der må godkende. Ligger al godkendelse hos lead developeren, er køen en organisatorisk sag. Fordel områderne, og lad de mindre erfarne gennemgå hinanden. Det vender vi tilbage til i lead developeren er blevet flaskehalsen.
Et godt spørgsmål til teamet er: hvor længe ligger en ændring typisk, før den får sit første svar? Kan ingen svare, er det et nyttigt første tal at få frem.
Hvad der kan vente
Fem udviklere har ikke brug for en stor ramme for agil udvikling med mange ceremonier og roller. Det, de fleste små team kan klare sig med, er en kort tavle over, hvad der er i gang, et ugentligt møde om prioriteter og en demo af virkende software, som ledelsen også kan se. Det hænger sammen med, hvordan I følger fremdriften uden selv at læse kode, se følg fremdriften uden at kunne kode.
Lange dokumenter om processen, omfattende målinger af den enkelte og faste møder uden en beslutning kan også vente. Sikkerhed hører derimod med fra begyndelsen, og den kan bygges ind i de samme rutiner. Hvordan det gøres, står i sikker softwareudvikling i et lille team.
Sådan kommer I i gang
Lav ikke det hele på én gang. Spørg teamet, hvilken af de fire rutiner der gør mest ondt i dag, og begynd der. En rimelig rækkefølge for de fleste er release først, automatisk test derefter og så de faste aftaler om gennemgang. Opfølgning på fejl kan begynde allerede ved næste hændelse og koster næsten ingenting.
Skriv aftalerne ned på én side, og lad teamet eje dem. Tag dem op, når I er vokset, for det, der passer til fem, passer ikke til tyve. Hvad der ændrer sig på vejen, kan I læse om under vækst i teamet.
Det skal I lade være med
- At købe et værktøj for at få en proces · værktøjet understøtter aftalerne, og uden aftalerne ændrer det intet.
- At indføre en stor metode på én gang · teamet mister tid og tillid, og I ved ikke, hvad der hjalp.
- At lade kodegennemgang være lead developerens opgave alene · så bygger I selv køen.
Det skal I kræve af den eksterne
- ☐ Et skriftligt billede af, hvordan en ændring kommer fra udvikler til kunde i dag.
- ☐ En vurdering af, hvilken af de fire rutiner der mangler mest.
- ☐ En plan for at indføre rutinerne, som teamet selv har været med til at lave.
- ☐ En forklaring uden fagord af, hvad ledelsen får ud af hver rutine.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvem ejer driften? · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
