Skriv en oppgavebeskrivelse til en agent

Beskriv en endring en reviewer kan vurdere

«Legg til kundeeksport» lar flere beslutninger stå åpne. Hvem kan eksportere poster? Hvilke poster og felt er inkludert? Hva skjer når en forespørsel feiler? En agent kan fylle hullene med plausible valg. Valgene kan fortsatt være feil for virksomheten.

Start med brukeren og problemet. Beskriv deretter påkrevd atferd. Ta med dokumentasjonen som vil vise om resultatet er akseptabelt.

En oppgavebeskrivelse bør redusere usikkerhet uten å låse hvert internt designvalg. Angi en påkrevd datagrense. La implementeringen bruke eksisterende repositorymønstre med mindre det finnes en grunn til å endre dem.

Bruk et konkret eksempel

Følgende oppgavebeskrivelse gjelder en fiktiv supportapplikasjon. Det er et pedagogisk eksempel, ikke en komplett produksjonsspesifikasjon.

Resultat: En supportleder kan laste ned en kundeliste.
Aktør: En leder i den aktuelle organisasjonen.
Data: Bare aktive kunder i den organisasjonen.
Felt: Kunde-ID, selskapsnavn og kontostatus.
Format: UTF-8 CSV med en overskriftsrad.
Avvist forespørsel: Returner den eksisterende autorisasjonsfeilen.
Tomt resultat: Returner en gyldig CSV med bare overskriften.
Omfang: Bruk eksisterende eksportroute og auditmønster.
Utelatt: Ingen nye roller, avhengigheter eller utrulling.
Dokumentasjon: Tester for tillatte, avviste, tomme og organisasjonskryssende forespørsler.

Beskrivelsen identifiserer nyttig atferd og grenser. Den avdekker også flere spørsmål. Bør systemet begrense eksportstørrelsen? Kan et felt inneholde en regnearkformel? Hvem kan få tilgang til auditregistreringen? Avklar vesentlige spørsmål før implementering. Ikke behandle eksemplet som en universell sjekkliste.

Skill krav fra antakelser

Et krav angir atferd endringen må oppfylle. En antakelse er et forhold du ennå ikke har verifisert. Hold dem atskilt.

For eksempel antar «bruk eksisterende auditmønster» at et egnet mønster finnes. Be agenten finne det. Hvis repositoryet ikke har noe, bør agenten rapportere den manglende avhengigheten før den finner opp et nytt auditsystem.

En begrensning kan også komme i konflikt med resultatet. Den eksisterende routen kan være laget for å returnere alle organisasjoner. Agenten bør vise konflikten og foreslå en avgrenset rettelse. Den bør ikke ubemerket fjerne datagrensen eller utvide oppgaven til omskriving av arkitekturen.

La fullføring omfatte dokumentasjon

Be om et leveransesammendrag som forklarer endelig atferd, endret omfang og utførte kontroller. Krev nøyaktige kommandoer og resultater der det er relevant. Skill en kontroll som besto, fra en som ikke kunne kjøres.

Pull requesten bør bevare begrunnelsen for endringen. En senere vedlikeholder kan se koden uten den opprinnelige samtalen. Ta med nok kontekst til å forklare hvorfor eksporten utelater bestemte felt, og hvordan tilgangen håndheves.

Googles veiledning for endringsbeskrivelser er en nyttig referanse. Beskrivelsen bør forklare endringen og formålet. Hold registreringen i samsvar med den endelige implementeringen etter reviewendringer.

Tilpass detaljnivået til oppgaven

En liten tekstendring kan ha en kort oppgavebeskrivelse. En dataeksport trenger flere detaljer fordi feil kan eksponere informasjon. En ny betalingsflyt trenger enda mer analyse og gjennomgang.

Ikke mål kvaliteten på oppgavebeskrivelsen etter lengden. Spør om en kompetent reviewer kan skille et riktig resultat fra et feil. Hvis to rimelige implementeringer ville være uenige om en vesentlig atferd, avklar den først.