Uzrakstiet aģentam uzdevuma aprakstu

Aprakstiet izmaiņu, ko pārskatītājs var novērtēt

„Pievienot klientu eksportu“ atstāj vairākus lēmumus neatrisinātus. Kas var eksportēt ierakstus? Kuri ieraksti un lauki ir iekļauti? Kas notiek, ja pieprasījums neizdodas? Aģents var aizpildīt šīs nepilnības ar ticamām izvēlēm. Šīs izvēles joprojām var būt biznesam nepareizas.

Sāciet ar lietotāju un problēmu. Tad aprakstiet prasīto darbību. Iekļaujiet pierādījumus, kas parādīs, vai rezultāts ir pieņemams.

Aprakstam jāsamazina nenoteiktība, nenosakot katru iekšējā risinājuma izvēli. Norādiet nepieciešamo datu robežu. Ļaujiet īstenojumam izmantot esošos repozitorija paraugus, ja vien nav iemesla tos mainīt.

Izmantojiet konkrētu piemēru

Tālāk sniegtais apraksts ir izdomātai atbalsta lietotnei. Tas ir mācību piemērs, nevis pilna produkcijas specifikācija.

Rezultāts: Atbalsta vadītājs var lejupielādēt klientu sarakstu.
Veicējs: Pašreizējās organizācijas vadītājs.
Dati: Tikai aktīvie klienti šajā organizācijā.
Lauki: Klienta ID, uzņēmuma nosaukums un konta statuss.
Formāts: UTF-8 CSV ar galvenes rindu.
Atteikts pieprasījums: Atgriezt esošo autorizācijas kļūdu.
Tukšs rezultāts: Atgriezt derīgu CSV tikai ar galveni.
Tvērums: Izmantot esošo eksporta maršrutu un audita paraugu.
Izslēgts: Nekādu jaunu lomu, atkarību vai izvietošanas.
Pierādījumi: Testi atļautiem, atteiktiem, tukšiem un starporganizāciju pieprasījumiem.

Šis apraksts nosaka noderīgu darbību un robežas. Tas arī atklāj turpmākus jautājumus. Vai sistēmai jāierobežo eksporta lielums? Vai lauks var saturēt izklājlapas formulu? Kas var piekļūt audita ierakstam? Atrisiniet būtiskos jautājumus pirms īstenošanas. Neuztveriet piemēru kā universālu kontrolsarakstu.

Atdaliet prasības no pieņēmumiem

Prasība nosaka darbību, kas izmaiņai jānodrošina. Pieņēmums ir fakts, kuru vēl neesat pārbaudījuši. Turiet tos atsevišķi.

Piemēram, „izmantot esošo audita paraugu“ paredz, ka piemērots paraugs pastāv. Lūdziet aģentam to atrast. Ja repozitorijā tāda nav, aģentam jāziņo par trūkstošo atkarību, pirms tas izdomā jaunu audita sistēmu.

Arī ierobežojums var būt pretrunā rezultātam. Esošais maršruts pēc sākotnējā risinājuma var atgriezt visas organizācijas. Aģentam jāparāda pretruna un jāpiedāvā ierobežots labojums. Tas nedrīkst klusējot noņemt datu robežu vai paplašināt uzdevumu līdz arhitektūras pārrakstīšanai.

Iekļaujiet pierādījumus pabeigšanā

Prasiet rezultāta kopsavilkumu, kas izskaidro galīgo darbību, mainīto tvērumu un veiktās pārbaudes. Kur tas svarīgi, prasiet precīzas komandas un rezultātus. Atšķiriet izturētu pārbaudi no pārbaudes, kuru nevarēja palaist.

Pull request jāsaglabā izmaiņas iemesls. Vēlāks uzturētājs var redzēt kodu bez sākotnējās sarunas. Iekļaujiet pietiekami daudz konteksta, lai izskaidrotu, kāpēc eksports neietver konkrētus laukus un kā tiek nodrošināta piekļuves kontrole.

Google norādes par izmaiņu aprakstiem ir noderīga atsauce šim ierakstam. Aprakstam jāizskaidro izmaiņa un tās nolūks. Pēc pārskatīšanas labojumiem saglabājiet ieraksta atbilstību galīgajam īstenojumam.

Saglabājiet aprakstu samērīgu

Nelielam teksta labojumam pietiek ar īsu aprakstu. Datu eksportam vajag vairāk detaļu, jo kļūmes var atklāt informāciju. Jaunai maksājumu darbplūsmai vajag vēl vairāk analīzes un pārskatīšanas.

Nevērtējiet apraksta kvalitāti pēc garuma. Jautājiet, vai kompetents pārskatītājs varētu atšķirt pareizu rezultātu no nepareiza. Ja divi saprātīgi īstenojumi atšķirtos būtiskā darbībā, vispirms precizējiet šo darbību.