Scrieți o descriere de sarcină pentru un agent

Descrieți o modificare care poate fi evaluată

„Adăugați exportul clienților” lasă mai multe decizii deschise. Cine poate exporta înregistrări? Ce înregistrări și câmpuri sunt incluse? Ce se întâmplă când o cerere eșuează? Un agent poate completa aceste goluri cu alegeri plauzibile. Ele pot fi totuși greșite pentru afacere.

Începeți cu utilizatorul și problema. Apoi descrieți comportamentul necesar. Includeți dovezile care vor arăta dacă rezultatul este acceptabil.

Descrierea trebuie să reducă incertitudinea fără a fixa fiecare alegere de proiectare internă. Precizați limita necesară pentru date. Lăsați implementarea să folosească tiparele existente în depozitul de cod, dacă nu există un motiv să le schimbe.

Folosiți un exemplu concret

Următoarea descriere privește o aplicație fictivă de suport. Este un exemplu educațional, nu o specificație completă pentru producție.

Rezultat: Un manager de suport poate descărca o listă de clienți.
Actor: Un manager din organizația curentă.
Date: Numai clienții activi ai acelei organizații.
Câmpuri: ID-ul clientului, numele companiei și starea contului.
Format: CSV UTF-8 cu un rând de antet.
Cerere refuzată: Returnați eroarea de autorizare existentă.
Rezultat gol: Returnați un CSV valid care conține doar antetul.
Domeniu: Folosiți ruta de export și tiparul de audit existente.
Excluderi: Fără roluri noi, dependențe noi sau instalare în mediu.
Dovezi: Teste pentru cereri permise, refuzate, fără rezultate și între organizații.

Descrierea identifică un comportament util și limitele sale. Scoate la iveală și alte întrebări. Ar trebui sistemul să limiteze dimensiunea exportului? Poate un câmp să conțină o formulă de foaie de calcul? Cine poate accesa înregistrarea de audit? Rezolvați întrebările cu consecințe importante înainte de implementare. Nu tratați exemplul ca pe o listă universală de verificare.

Separați cerințele de ipoteze

O cerință precizează un comportament pe care modificarea trebuie să îl respecte. O ipoteză este un fapt pe care încă nu l-ați verificat. Păstrați-le separate.

De exemplu, „Folosiți tiparul de audit existent” presupune că există un tipar potrivit. Cereți agentului să îl găsească. Dacă depozitul de cod nu conține unul, agentul trebuie să raporteze dependența lipsă înainte de a inventa un sistem nou de audit.

O constrângere poate și să contrazică rezultatul dorit. Ruta existentă poate returna intenționat toate organizațiile. Agentul trebuie să arate conflictul și să propună o corecție limitată. Nu trebuie să elimine în tăcere limita pentru date sau să extindă sarcina într-o rescriere a arhitecturii.

Includeți dovezile în condiția de terminare

Cereți un rezumat al livrării care explică comportamentul final, schimbarea domeniului și verificările executate. Solicitați comenzi și rezultate exacte acolo unde contează. Deosebiți o verificare încheiată cu succes de una care nu a putut fi executată.

Pull request-ul trebuie să păstreze motivul modificării. O persoană care asigură ulterior mentenanța poate vedea codul fără conversația inițială. Includeți suficient context pentru a explica de ce exportul exclude anumite câmpuri și cum este impus controlul accesului.

Ghidul Google privind descrierea modificărilor este o referință utilă pentru această consemnare. Descrierea trebuie să explice modificarea și scopul ei. Actualizați consemnarea după schimbările din verificare, astfel încât să corespundă implementării finale.

Păstrați proporțiile descrierii

O corecție mică de text poate avea o descriere scurtă. Un export de date necesită mai multe detalii deoarece defecțiunile sale pot expune informații. Un flux nou de plăți necesită și mai multă analiză și verificare.

Nu măsurați calitatea descrierii prin lungime. Întrebați-vă dacă o persoană competentă ar putea deosebi un rezultat corect de unul incorect. Dacă două implementări rezonabile ar putea avea comportamente diferite cu consecințe importante, clarificați mai întâi comportamentul respectiv.