Shkruani një përshkrim detyre për një agjent

Përshkruani një ndryshim që shqyrtuesi mund ta vlerësojë

‘Shtoni eksportin e të dhënave të klientëve’ lë disa vendime të hapura. Kush mund të eksportojë rekorde? Cilat rekorde dhe fusha përfshihen? Çfarë ndodh kur një kërkesë dështon? Një agjent mund t’i plotësojë këto boshllëqe me zgjedhje që duken të arsyeshme. Ato ende mund të jenë të gabuara për biznesin.

Nisni me përdoruesin dhe problemin. Pastaj përshkruani sjelljen e kërkuar. Përfshini evidencën që do të tregojë nëse rezultati është i pranueshëm.

Përshkrimi duhet të ulë pasigurinë pa përcaktuar paraprakisht çdo zgjedhje të projektimit të brendshëm. Përcaktoni kufirin e kërkuar të të dhënave. Lejojeni implementimin të përdorë modelet ekzistuese të depos së kodit, përveç rasteve kur ka arsye për t’i ndryshuar.

Përdorni një shembull konkret

Përshkrimi i mëposhtëm është për një aplikacion të sajuar mbështetjeje. Është shembull mësimor, jo specifikim i plotë për prodhim.

Rezultati: Një menaxher mbështetjeje mund të shkarkojë një listë klientësh.
Vepruesi: Një menaxher në organizatën aktuale.
Të dhënat: Vetëm klientët aktivë në atë organizatë.
Fushat: ID e klientit, emri i kompanisë dhe statusi i llogarisë.
Formati: CSV UTF-8 me rresht titujsh.
Kërkesë e refuzuar: Ktheni gabimin ekzistues të autorizimit.
Rezultat bosh: Ktheni një CSV të vlefshëm vetëm me titujt.
Fusha: Përdorni route-in ekzistues të eksportit dhe modelin e auditimit.
Të përjashtuara: Asnjë rol i ri, varësi e re ose vendosje.
Evidenca: Teste për kërkesa të lejuara, të refuzuara, boshe dhe ndërmjet organizatave.

Ky përshkrim identifikon sjellje dhe kufij të dobishëm. Nxjerr edhe pyetje të tjera. A duhet ta kufizojë sistemi madhësinë e eksportit? A mund të përmbajë një fushë formulë për fletëllogaritje? Kush mund të hyjë te regjistri i auditimit? Zgjidhni pyetjet me pasoja të rëndësishme para implementimit. Mos e trajtoni shembullin si listë universale kontrolli.

Ndani kërkesat nga supozimet

Një kërkesë përcakton sjelljen që ndryshimi duhet të përmbushë. Një supozim është një fakt që ende nuk e keni verifikuar. Mbajini të ndara.

Për shembull, ‘Përdorni modelin ekzistues të auditimit’ supozon se ekziston një model i përshtatshëm. Kërkojini agjentit ta gjejë. Nëse depoja e kodit nuk e ka, agjenti duhet ta raportojë varësinë e munguar para se të shpikë një sistem të ri auditimi.

Një kufizim mund të bjerë ndesh edhe me rezultatin. Route-i ekzistues mund të jetë projektuar për të kthyer çdo organizatë. Agjenti duhet ta tregojë konfliktin dhe të propozojë një korrigjim të kufizuar. Nuk duhet ta heqë në heshtje kufirin e të dhënave ose ta zgjerojë detyrën në rishkrim të arkitekturës.

Përfshijeni evidencën në përfundim

Kërkoni një përmbledhje dorëzimi që shpjegon sjelljen përfundimtare, fushën e ndryshuar dhe kontrollet e kryera. Kërkoni komandat dhe rezultatet e sakta aty ku kanë rëndësi. Dalloni një kontroll që kaloi nga një kontroll që nuk mund të ekzekutohej.

Pull request-i duhet ta ruajë arsyen e ndryshimit. Një mirëmbajtës i ardhshëm mund ta shohë kodin pa bisedën origjinale. Përfshini kontekst të mjaftueshëm për të shpjeguar pse eksporti përjashton fusha të caktuara dhe si zbatohet kontrolli i aksesit.

Udhëzimi i Google për përshkrimet e ndryshimeve është referencë e dobishme për këtë regjistër. Përshkrimi duhet të shpjegojë ndryshimin dhe qëllimin e tij. Mbajeni regjistrin në përputhje me implementimin përfundimtar pas ndryshimeve nga shqyrtimi.

Mbajeni përshkrimin në përpjesëtim me detyrën

Një korrigjim i vogël teksti mund të ketë përshkrim të shkurtër. Një eksport të dhënash kërkon më shumë hollësi sepse dështimet e tij mund të ekspozojnë informacion. Një rrjedhë e re pagesash kërkon edhe më shumë analizë dhe shqyrtim.

Mos e matni cilësinë e përshkrimit nga gjatësia. Pyesni nëse një shqyrtues kompetent mund të dallojë një rezultat të saktë nga një i pasaktë. Nëse dy implementime të arsyeshme do të ndryshonin për një sjellje me pasoja të rëndësishme, sqarojeni fillimisht atë sjellje.