Napišite opis zadatka za agenta

Opišite promjenu koju pregledavatelj može procijeniti

„Dodajte izvoz klijenata” ostavlja više odluka otvorenima. Tko može izvoziti zapise? Koji su zapisi i polja uključeni? Što se događa ako zahtjev ne uspije? Agent može popuniti praznine uvjerljivim odlukama. One i dalje mogu biti pogrešne za poslovanje.

Počnite korisnikom i problemom. Zatim opišite potrebno ponašanje. Uključite dokaze koji će pokazati je li rezultat prihvatljiv.

Opis zadatka treba smanjiti nesigurnost bez određivanja svake unutarnje projektne odluke. Navedite potrebnu granicu podataka. Neka implementacija upotrebljava postojeće obrasce repozitorija ako nema razloga za njihovu promjenu.

Upotrijebite konkretan primjer

Sljedeći opis odnosi se na izmišljenu aplikaciju za podršku. To je obrazovni primjer, a ne potpuna produkcijska specifikacija.

Rezultat: Voditelj podrške može preuzeti popis klijenata.
Izvršitelj: Voditelj u trenutačnoj organizaciji.
Podaci: Samo aktivni klijenti te organizacije.
Polja: ID klijenta, naziv tvrtke i status računa.
Format: UTF-8 CSV s retkom zaglavlja.
Odbijeni zahtjev: Vratite postojeću pogrešku autorizacije.
Prazan rezultat: Vratite valjan CSV samo sa zaglavljem.
Opseg: Upotrijebite postojeću rutu izvoza i obrazac revizijskog zapisivanja.
Isključeno: Bez novih uloga, ovisnosti ili postavljanja u okruženje.
Dokazi: Testovi dopuštenih, odbijenih, praznih i međuorganizacijskih zahtjeva.

Opis utvrđuje korisno ponašanje i ograničenja. Također otkriva daljnja pitanja. Treba li sustav ograničiti veličinu izvoza? Može li polje sadržavati formulu proračunske tablice? Tko može pristupiti revizijskom zapisu? Prije implementacije riješite pitanja s važnim posljedicama. Nemojte primjer tretirati kao univerzalan kontrolni popis.

Odvojite zahtjeve od pretpostavki

Zahtjev navodi ponašanje koje promjena mora zadovoljiti. Pretpostavka je činjenica koju još niste provjerili. Držite ih odvojene.

Primjerice, „upotrijebite postojeći obrazac revizijskog zapisivanja” pretpostavlja da prikladan obrazac postoji. Zatražite da ga agent pronađe. Ako ga repozitorij nema, agent treba prijaviti ovisnost koja nedostaje prije osmišljavanja novog revizijskog sustava.

Ograničenje može proturječiti i rezultatu. Postojeća ruta možda namjerno vraća sve organizacije. Agent treba pokazati sukob i predložiti ograničen ispravak. Ne smije prešutno ukloniti granicu podataka ni proširiti zadatak na prepisivanje arhitekture.

Uključite dokaze u završetak

Zatražite sažetak isporuke koji objašnjava konačno ponašanje, promijenjeni opseg i provedene provjere. Gdje je važno, tražite točne naredbe i rezultate. Razlikujte uspješnu provjeru od one koju nije bilo moguće pokrenuti.

Pull request treba sačuvati razlog promjene. Kasniji održavatelj može vidjeti kod bez izvornog razgovora. Uključite dovoljno konteksta da objasnite zašto izvoz isključuje određena polja i kako se provodi kontrola pristupa.

Googleove smjernice za opis promjene korisna su referenca za taj zapis. Opis treba objasniti promjenu i njezinu svrhu. Nakon promjena tijekom pregleda uskladite zapis s konačnom implementacijom.

Prilagodite opseg opisa zadatku

Mali tekstni ispravak može imati kratak opis. Izvoz podataka treba više detalja jer njegovi kvarovi mogu otkriti informacije. Novi postupak plaćanja zahtijeva još više analize i pregleda.

Nemojte mjeriti kvalitetu opisa njegovom duljinom. Pitajte bi li stručan pregledavatelj mogao razlikovati točan rezultat od pogrešnog. Ako bi se dvije razumne implementacije razlikovale u ponašanju s važnim posljedicama, prvo razjasnite to ponašanje.