” cerere caracteristică!!!”
este adesea strigătul de luptă pe care inginerii de software îl folosesc pentru a minimiza urgența problemei unui client. La urma urmei, nu este timp să adăugăm noi funcții atunci când ne uităm la Jurnalul de erori fără sfârșit care ne confruntă.
pentru inginerii software din SUA, diferența dintre o eroare și o solicitare de caracteristici este clară. Un bug este o discrepanță între modul în care codul este de fapt de lucru și modul în care codul nostru a fost destinat să funcționeze. O solicitare de caracteristici necesită un cod nou pentru a satisface un caz care nu poate fi gestionat de baza de cod curentă.
acest tip de proces de gândire ne conduce întotdeauna la întrebarea mai generală a modului în care ar trebui folosit software-ul ca DoneDone. Ar trebui ca organizația dvs. să utilizeze un tip de software pentru a înregistra erori, un alt tip de software pentru a gestiona sarcinile viitoare și încă un tip de software pentru a urmări solicitările de caracteristici?
cheltuim multă energie mentală încercând să trecem prin problemele înregistrate de un client sau client, încercând să determinăm dacă aruncăm o problemă în găleata „bug” sau în găleata „feature request”. Pentru activitatea de consultanță, atunci când lucrăm la un acord predefinit despre modul în care ar trebui să se comporte software-ul, acest lucru are sens. Cererile de caracteristici ar putea necesita o taxă suplimentară.
dar, când vine vorba doar de practica pură de a construi un software bun, în special dacă lucrăm la propriile noastre produse, cât de mult ar trebui să ne pese să clasificăm o problemă în acest fel?
lăsăm tehnicitățile (și tehnologia) să împiedice rezolvarea problemelor.
Robert Martin (alias unchiul Bob) vorbește mult despre software. El consideră Internetul doar un mecanism de livrare și nimic mai mult. Nu este experiența utilizatorului final și nu este scopul software-ului. Este pur și simplu un mic detaliu prost. Cu toate acestea, atunci când programăm programatorii, arhitectura aplicațiilor noastre este prea în întregime influențată de faptul că este o aplicație Web.
în același mod, ce se întâmplă dacă am considera termenul pe care îl folosim pentru „un lucru care trebuie făcut” ca fiind un detaliu prost?
din punctul de vedere al persoanei care înregistrează acel „lucru”, contează cu adevărat pentru ea că solicită o caracteristică nouă față de descoperirea unui bug? Vrea doar ca problema ei să fie rezolvată de o altă ființă umană și, de preferință, să știe când problema ei ar putea fi rezolvată.
s-ar putea să vedeți tehnicitatea mai evident dacă părăsim lumea software-ului. Când instalatorul vine să repare dușul neetanș, îmi imaginez că nu-ți pasă de detalii. Dacă capul de duș a fost instalat incorect (bug) sau dacă garnitura este ruptă (bug) sau dacă banda de teflon lipsea dintr-o țeavă ieftină (caracteristică), tot ce vă interesează este cât timp va dura pentru a repara și cât veți fi taxat.
Bug sau cerere? Sunt amândouă. Și, nu contează.
săptămâna trecută suntem mamut lansat Kin, un instrument software de resurse umane pentru întreprinderile mici. Kin vă oferă o modalitate simplă de a urmări cererile de timp libere ale fiecărui angajat. Un lucru pe care rudele nu îl fac acum este să distingă weekendurile și sărbătorile de zilele lucrătoare. Deci, dacă doriți să decolați o săptămână întreagă în timpul Zilei Recunoștinței, trebuie să introduceți manual numărul de ore pe care le solicitați.
echipa a primit deja câteva solicitări pentru ca rudele să facă această urmărire automat. De fapt, este în coada de lansare. Dar, când este conectat, în orice loc este conectat, ar trebui ca echipa Kin să o considere o eroare, o solicitare de caracteristici, o sarcină sau o sarcină?
sunându-l pe unchiul meu interior Bob, răspunsul meu este simplu: nu contează cum clasificați cererea. E doar un detaliu prostesc.
asta nu înseamnă că nu ar trebui să-l clasificăm deloc. Echipa Kin ar putea eticheta problema sub „cerere caracteristică” și să lucreze mai întâi la remedierea problemelor mai critice (cum ar fi un utilizator cu o problemă de autorizare). Asta e bine și dandy, și o abordare validă.
cu toate acestea, ar fi o greșeală să presupunem automat toate lucrurile-noi-apelăm-cererile de caracteristici sunt mai puțin urgente decât toate lucrurile-noi-apelăm-bug-uri. Asta face ca detaliile minore ale modului în care clasificăm problema să fie elementul central atunci când o rezolvăm. Nu ar trebui să fie așa. La sfârșitul zilei, toate aceste cereri sunt pur și simplu lucruri care au nevoie de rezolvare.
fie ca tehnicitatea să fie detaliul prost
în acest scop, eticheta pe care o dăm tuturor acestor cereri este în mare măsură neimportantă. Ceea ce contează mai mult este că cineva este participarea la ele și există o idee generală de când aceste cereri vor fi abordate. Ceea ce contează mai mult este că 33% mai mulți utilizatori vor beneficia de elementul a adresat față de elementul B. indiferent de ce tip de element de lucru a sau elementul B este, elementul a este mai valoros pentru a aborda. Asta e. Nimic mai mult.
Deci, data viitoare când petreci prea mult timp cu sarcini de clasificare, bug-uri, cereri de caracteristici, și să-dos, amintiți-vă să uitați detaliile tehnice. Sunt doar detaliile stupide.
Înscrieți-vă pentru un cont DoneDone în 30 de secunde. Vrei să citești mai mult de Ka wai Cheung? Noua carte a lui Ka Wai despre programatorul modern, codul dezvoltatorului, este disponibilă în cărți electronice și tipărite. Îl puteți urmări pe Twitter @ developerscode.