AI-agent til daglig sprintstatus: dit GitHub-repository opsummeret hver morgen i en wiki

En brugbar sprintstatus er kort, dateret og sammenlignelig fra dag til dag. Den er også besværlig at lave: man skal åbne repositoryet, tælle flettede pull requests, finde dem, der venter på review, gennemgå issues, tjekke om en release nærmer sig og skrive to afsnit, som ingen har tid til at pudse af. Som regel findes statussen ikke, eller den klaskes sammen lige før mødet, og blokeringerne opdages for sent. Det er en ideel opgave for en autonom AI-agent: den gentages ens, bygger på data, der allerede er struktureret, og kan kontrolleres med et blik.

Inspirationen: morgenstatussen, som ingen samlede

Udgangspunktet er en brug, der beskrives i beretninger fra folk, der kører autonome agenter: agenter, der læser udviklingsteamets værktøjer, tæller, hvad der er sket, og lægger en sprintrapport hver morgen. Det, der går igen i beretningerne, er ikke datamængden, men regelmæssigheden: statussen findes hver dag med samme opbygning, så man kan se tendenser i stedet for at reagere på ét enkelt tal.

Atako tager ideen op med én agent og ét resultat. Agenten læser GitHub, regner, skriver og udgiver. Den ændrer intet i repositoryet, og rapporten er det eneste, den producerer.

Hvad agenten gør

Leveranceanalytikeren læser repositoryet i GitHub, det du angiver som ejer/navn. Ved hver kørsel følger den en fast metode.

Først tæller den over syv rullende dage fra dags dato de flettede pull requests, dem der stadig er åbne med deres alder, dem der har ventet på review i mere end tre dage, åbnede og lukkede issues og udgivne releases. Derefter finder den blokeringerne: pull requests åbne i mere end fem dage, issues der hober sig op om samme emne, en release der er forsinket i lyset af commits. Hver angives med link og forfatter. Til sidst sammenligner den med de foregående syv dage og siger, hvad der har rykket sig.

Så skriver den en ny side «Sprintstatus - » efterfulgt af dagens dato i projektets wiki. Findes dagens side allerede, opdaterer den den i stedet for at oprette en anden. Opbygningen ændrer sig ikke: de tre eller fire tal, der tæller, fremdriften i forhold til forrige periode, blokeringerne og de pull requests, der bliver liggende, og de beslutninger, der kan overvejes. Den starter med konklusionen, læses på to minutter og opsummerer det vigtigste i chatten.

Hvad agenten ikke gør

Analytikeren læser, den skriver aldrig i GitHub: ingen kommentar, mærkat, review, fletning eller lukning. Den pusher ingen kode. Den kontakter ingen: rapporten og chatten er dens eneste udgange. Den opfinder aldrig et tal eller et link, og en manglende oplysning skrives «ikke tilgængelig».

Hver dag har sin side: agenten overskriver aldrig en tidligere dag, så der er en historik, som teamet kan genlæse. Fakta holdes adskilt fra fortolkning, og fortolkningen er markeret som sådan. Rapporten foreslår prioriteter, men pålægger dem ikke: det er princippet bag et design med menneskelig godkendelse.

Sådan sætter du det op i Atako

Fra siden for dette anvendelsestilfælde tager udrulningen fire trin.

1. Forbind GitHub. Giv Atako læseadgang til det repository, der skal følges, når der bliver spurgt. Forbindelsen kontrolleres, før noget oprettes.
2. Angiv din kontekst. Angiv repositoryet som ejer/navn og hvem der læser rapporten, så tonen passer.
3. Rul ud. Én handling opretter agenten og projektet «Sprintstatus». Agenten klargøres og får selv sine første instruktioner.
4. Første status, derefter daglig rytme. Analytikeren laver den første rapport for de seneste syv dage og planlægger derefter selv sin kørsel kl. 8.00 hver morgen.

Hvis du endnu ikke har en konto, starter oprettelsen af den din prøveperiode, og scenariet konfigureres lige efter. Hvis din administrator ikke har givet dig lov til at oprette agenter, fortæller udrulningen det og stopper der.

Hvor du ser resultaterne

Rapporten ligger i wikien i projektet «Sprintstatus», én side pr. dag, fra den nyeste til den ældste. Agentens resumé lander også i dens chat, så du kan læse det vigtigste på telefonen, før du åbner siden. På Atako-gulvet vises analytikeren med sin aktivitet: du kan se, hvornår den læser repositoryet, og hvornår den skriver, uden at spørge, hvor langt statussen er.

Du kan tale med den i dens chat. Spørg, hvor et tal kommer fra, bed den beskrive en blokering, følge et andet repository eller lave statussen om med en anden vinkel. Agenten husker sine tidligere kørsler.

Sikkerhedsforanstaltninger

Adgangen er bevidst smal og skrivebeskyttet: otte GitHub-værktøjer til at liste repositories, læse et repository, liste og læse pull requests, liste og søge issues og liste commits og releases. En agent, der ser en kort værktøjsliste, bruger dem mere pålideligt end en, der farer vild i et katalog med hundredvis. Intet gives som standard, og enhver adgang kan til enhver tid fjernes i Atako.

Den menneskelige godkendelse sidder på beslutningen. Rapporten peger på blokeringer og pull requests, der bliver liggende; det er teamet, der vælger, om det vil minde en reviewer om det, dele en pull request op eller udskyde en release. Agenten ser kun det, GitHub giver den: en pull request uden beskrivelse eller et repository med umærkede issues giver en mindre præcis status, og rapporten siger det i stedet for at skjule det.

Hvad du kan forvente

Forvent en første status, der er brugbar, men stadig generel, og som bliver præcis, når du i chatten har justeret læsere og tærskler, for eksempel ved at bede den markere pull requests, der har ventet på review i to dage i stedet for tre. Værdien kommer af gentagelsen: efter to uger lader de på hinanden følgende sider dig sammenligne og se, hvilken blokering der varer ved, og hvilken tendens der tegner sig. For et lille teknisk team er det forskellen på en oversigt rekonstrueret fra hukommelsen før mødet og en daglig status, der bare findes, med de samme definitioner hver dag.