Napišite opis zadatka za agenta

Opišite promjenu koju osoba zadužena za pregled može procijeniti

„Dodajte izvoz podataka o klijentima“ ostavlja nekoliko odluka otvorenim. Ko može izvoziti zapise? Koji zapisi i polja ulaze u izvoz? Šta se desi kada zahtjev ne uspije? Agent može popuniti ove praznine uvjerljivim izborima. Ti izbori i dalje mogu biti pogrešni za poslovanje.

Počnite od korisnika i problema. Zatim opišite traženo ponašanje. Uključite dokaze koji će pokazati je li rezultat prihvatljiv.

Opis zadatka treba smanjiti neizvjesnost bez određivanja svakog internog dizajnerskog izbora. Navedite potrebnu granicu podataka. Neka implementacija koristi postojeće obrasce repozitorija, osim ako postoji razlog za njihovu promjenu.

Koristite konkretan primjer

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

Ishod: Menadžer podrške može preuzeti listu klijenata.
Akter: Menadžer u trenutnoj organizaciji.
Podaci: Samo aktivni klijenti te organizacije.
Polja: ID klijenta, naziv kompanije i status računa.
Format: UTF-8 CSV s redom zaglavlja.
Odbijeni zahtjev: Vratite postojeću grešku autorizacije.
Prazan rezultat: Vratite važeći CSV samo sa zaglavljem.
Opseg: Koristite postojeću rutu za izvoz i obrazac revizijskog bilježenja.
Isključeno: Nema novih uloga, zavisnosti ni raspoređivanja.
Dokazi: Testovi za dozvoljene i odbijene zahtjeve, prazne rezultate i zahtjeve za drugu organizaciju.

Ovaj opis utvrđuje korisno ponašanje i ograničenja. Otkriva i dodatna pitanja. Treba li sistem ograničiti veličinu izvoza? Može li polje sadržavati formulu za tabelarni proračun? Ko može pristupiti revizijskom zapisu? Riješite pitanja s važnim posljedicama prije implementacije. Nemojte tretirati primjer kao univerzalnu kontrolnu listu.

Odvojite zahtjeve od pretpostavki

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

Naprimjer, „Koristite postojeći obrazac revizijskog bilježenja“ pretpostavlja da pogodan obrazac postoji. Zatražite da ga agent pronađe. Ako ga repozitorij nema, agent treba prijaviti zavisnost koja nedostaje prije nego što izmisli novi sistem revizijskog bilježenja.

Ograničenje može biti i u sukobu s ishodom. Postojeća ruta možda je namjerno napravljena tako da vraća sve organizacije. Agent treba pokazati sukob i predložiti ograničenu ispravku. Ne treba prešutno ukloniti granicu podataka niti proširiti zadatak na prepisivanje arhitekture.

Uključite dokaze u uslov završetka

Zatražite sažetak isporuke koji objašnjava konačno ponašanje, izmijenjeni opseg i izvršene provjere. Zahtijevajte tačne naredbe i rezultate tamo gdje su važni. Razlikujte provjeru koja je prošla od provjere koja se nije mogla izvršiti.

Zahtjev za spajanje koda treba sačuvati razlog promjene. Buduća osoba zadužena za održavanje može vidjeti kod bez prvobitnog razgovora. Uključite dovoljno konteksta da objasnite zašto izvoz isključuje određena polja i kako se provode pravila pristupa.

Googleove smjernice za opis promjena korisna su referenca za ovaj zapis. Opis treba objasniti promjenu i njenu svrhu. Uskladite zapis s konačnom implementacijom nakon izmjena tokom pregleda.

Prilagodite opis veličini zadatka

Mala ispravka teksta može imati kratak opis. Izvoz podataka treba više detalja jer neuspjesi mogu izložiti informacije. Novi radni tok plaćanja zahtijeva još više analize i pregleda.

Nemojte mjeriti kvalitet opisa dužinom. Pitajte bi li stručna osoba zadužena za pregled mogla razlikovati tačan rezultat od netačnog. Ako bi se dvije razumne implementacije razlikovale u ponašanju s važnim posljedicama, prvo razjasnite to ponašanje.