Brug korte forløb til at reducere usikkerhed
Bevar de korte forløb og den hyppige feedback, men lad hvert AI-eksperiment besvare et vigtigt spørgsmål. En iteration er kun lærerig, når observationen kan ændre næste beslutning. Planlæg både afprøvning, faglig vurdering og dokumentation, så teamet ikke blot producerer en ny demonstration hver anden uge.
Scrum bygger på inspektion og tilpasning i korte forløb. [1] Det kan give en nyttig arbejdsrytme for AI. Rytmen afgør dog ikke, om forsøget er godt. En sprogmodel kan levere overbevisende eksempler, selv om den ikke fungerer på den variation, som virksomhedens virkelige opgaver indeholder.
Læringen er derfor at kombinere en agil leverancerytme med et tydeligt forsøgsdesign. Design et AI eksperiment der giver et brugbart svar (Q07) beskriver hypoteser og afprøvning, mens Vurdér kvaliteten af AI svar og handlinger (Q24) behandler kvalitetsvurdering. Denne artikel fokuserer på, hvordan ledelsen undgår at forveksle korte forløb med hurtig dokumentation for værdi.
Vælg den usikkerhed der påvirker næste investering
Start med den beslutning, virksomheden står over for. Skal den investere i bedre dokumenter, en integration eller en MVP? Find derefter den antagelse, som mest kan ændre valget. Det kan være datadækning, faglig kvalitet, brugerbehov eller praktisk adgang til systemet.
Et forsøg bør normalt have et afgrænset hovedspørgsmål. Hvis teamet samtidig ændrer model, datakilder, instruktioner og brugerproces, bliver det vanskeligt at forklare resultatet. Flere ændringer kan være nødvendige, men de skal dokumenteres, og forsøgets begrænsninger skal fremgå.
Beskriv på forhånd mulige udfald: fortsæt, tilpas, stop eller undersøg mere. Et kriterium skal være relevant for opgavens konsekvens. Der findes ikke en universel korrekthedsprocent, som gør alle AI-løsninger klar til brug.
Forbind iterationen med et bevis
| Del af forløbet | Agil praksis | AI specifik tilføjelse |
|---|---|---|
| Planlægning | Vælg et afgrænset mål | Angiv hypotese, testgrundlag og beslutningskriterium |
| Gennemførelse | Byg og undersøg en brugbar ændring | Registrér model, instruktioner, data og variation |
| Gennemgang | Vis resultat og indhent feedback | Vis også fejl, undtagelser og faglig bedømmelse |
| Tilpasning | Ændr næste prioritet | Opdatér antagelser uden at tilpasse testen til et ønsket svar |
Agile principper opfordrer til regelmæssig refleksion og tilpasning. [2] I AI-arbejde skal refleksionen også handle om kvaliteten af vores egen evaluering. Hvis testeksemplerne kun dækker lette situationer, kan en forbedring i målingen være mindre værd end den ser ud.
Brug repræsentative eksempler og bevar en kontrol
Saml typiske opgaver, sjældne men væsentlige undtagelser og situationer, hvor løsningen bør afvise eller bede om hjælp. Fjern eller beskyt følsomme oplysninger efter de aftalte rammer. Lad fagpersoner beskrive, hvad et brugbart resultat kræver.
Når teamet forbedrer løsningen ud fra et testsæt, bliver det gradvist en del af udviklingsarbejdet. Bevar derfor også eksempler, som ikke bruges til løbende tilpasning. Gentag relevante forsøg, når modellens variation kan påvirke konklusionen.
Anthropics materiale om evaluering beskriver blandt andet betydningen af realistiske opgaver og flere former for bedømmelse. [3] En anden model kan hjælpe med at sortere resultater, men dens vurdering skal kontrolleres mod faglig bedømmelse. Den er ikke automatisk en uafhængig sandhed.
Et eksempel hvor et afkræftet forsøg sparer arbejde
Grossisten i dette eksempel vil automatisk matche kundernes fritekst til produktnumre. Det første forsøg undersøger, om modellen kan skelne mellem næsten ens varianter på et repræsentativt udvalg. Den klarer standardbeskrivelser, men fejler ved forkortelser og afgørende mål.
Teamet viser fejltyperne og anbefaler en afgrænset søgeassistent med menneskeligt valg. Ledelsen finansierer et nyt forsøg med bedre produktdata, før automatisk ordreoprettelse overvejes. Den oprindelige hypotese er ikke bekræftet, men næste investering er blevet mere præcis.
Hvis teamet alene var blevet bedømt på færdige funktioner, kunne det have bygget ordrehandlingen oven på et usikkert match. Den korte iteration gav værdi, fordi et vigtigt resultat fik lov til at ændre planen.
Skift fra teknisk mulighed til virkelig brug
EnableAIs tre stadier skelner mellem eksperiment, MVP og skalering. [4] Eksperimentet undersøger muligheden under kontrollerede forhold. MVP’en undersøger, om løsningen hjælper rigtige brugere i en virkelig proces. Skalering undersøger gentagelighed, drift og bredere variation.
Brug korte forløb i alle tre stadier, men tilpas spørgsmålet. Et nyt team eller en ny datakilde ved skalering kan kræve et målrettet eksperiment. Stadierne er en investeringslogik, ikke en envejsplan, hvor al usikkerhed skal være fjernet før næste skridt.
Aftal også, hvornår mere afprøvning ikke længere er pengene værd. Hvis en usikkerhed kun kan afklares gennem rigtig brug, kan en sikkert afgrænset MVP være næste skridt. Hvis konsekvensen er for stor, må rammerne ændres først.
Næste ledelsesbeslutning: Bed det næste forløb begynde med én beslutning, én afgørende antagelse og et troværdigt testgrundlag. Gennemgå fejl og begrænsninger sammen med de vellykkede eksempler.
Kundeeksempel med mål og opfølgning
I rekrutteringsfirmaets eksempel er den centrale usikkerhed, om kandidatpræsentationer kan forberedes væsentligt hurtigere med uændret faktuel kvalitet. Et testresultat på 35 minutter mod et kriterium på højst 25 minutter giver grundlag for at ændre retning.
Læringen dokumenteres gennem opgaver, tidsmålinger og rettelser. Et fravalgt videre budget er ikke automatisk en kontant besparelse; den konkrete værdi er et bedre valg, mindre eksponering og mulighed for at bruge kapaciteten på noget mere lovende.
Brug den samlede VP/SE-model, VP-vejledningen og SE-vejledningen. Begge estimater revurderes før Hypotese, MVP og Skalering. VP/SE er et lokalt præferenceindeks, ikke økonomisk ROI eller WSJF. Lær anvendelsen på halvdag 1 om VP og halvdag 2 om SE og prioritering, hver fire timer inklusive pause.
Kilder og videre læsning
Eksempler og handlingsforslag er EnableAIs faglige vurdering. Virksomhedseksempler og regnetal er illustrative. Artiklen er opdateret med konkrete regneeksempler og henvisninger den 15. september 2026.
[1] Schwaber og Sutherland · Scrum Guide 2020
[2] Principperne bag Det Agile Manifest