9 valori care pot face diferența pentru echipele de dezvoltare software de astăzi

după cum am menționat în articolul „de ce valorile nu contează în dezvoltarea de software (cu excepția cazului în care le asociați cu obiectivele de afaceri)”, alegerea valorilor necesită o gândire și o atenție considerabilă pentru a sprijini întrebările specifice pe care o afacere trebuie să le răspundă. Iată punctul critic: măsurătorile ar trebui concepute doar ca o modalitate de a răspunde la întrebările de afaceri. Și aceste întrebări nu sunt niciodată, ” câți KLOCs suntem până acum?”

acest articol preia de unde a rămas precedentul, discutând mai întâi valorile specifice pe care fiecare echipă ar trebui să le utilizeze sau cel puțin intenționează să le utilizeze în curând ca o modalitate de a îmbunătăți performanța vizibilă. Rețineți că titlul acestui articol susține că există „9 valori care pot face diferența…”—pentru că ceea ce este cu adevărat important, ceea ce va face cu adevărat diferența, este modul în care aceste valori sunt de fapt utilizate pentru a îmbunătăți valoarea afacerii. Această utilizare depinde de tine. Apoi, acest articol se încheie explicând modul în care puteți combina aceste valori pentru a crea sens, precum și pentru a formula și testa o ipoteză a valorii afacerii.

începeți prin măsurarea lucrurilor potrivite

iată nouă valori obiective (marcate cu puncte glonț) pe care ar trebui să le monitorizați continuu, pentru a îmbunătăți incremental procesele și mediile de producție. Îmbunătățirile acestor numere nu vor garanta că nivelul de satisfacție al clienților dvs. va crește cu pași mari. Dar cel puțin acestea sunt lucrurile corecte de măsurat. Într-o secțiune ulterioară a acestui articol, „punerea totul împreună,” veți vedea de ce.

agile process metrics

pentru procesele agile și lean, valorile de bază sunt leadtime, timpul ciclului, viteza echipei și ratele de deschidere/închidere. Aceste valori ajută la planificarea și informarea deciziilor cu privire la îmbunătățirea procesului. Deși nu măsoară succesul sau valoarea adăugată și nu au nicio legătură cu calitatea obiectivă a software-ului, ar trebui să le măsurați oricum. Voi explica de ce mai jos.

• Leadtime—cât timp îți ia să treci de la idee la software livrat. Dacă doriți să fiți mai receptivi la clienții dvs., lucrați pentru a reduce timpul de plumb, de obicei prin simplificarea luării deciziilor și reducerea timpului de așteptare. Leadtime include timpul ciclului.
• durata ciclului—cât timp îți ia să faci o schimbare în sistemul tău software și să livrezi acea schimbare în producție. Echipele care utilizează livrarea continuă pot avea timpi de ciclu măsurați în minute sau chiar secunde în loc de luni.
• viteza echipei—câte „unități” de software completează echipa de obicei într-o iterație (alias „sprint”). Acest număr trebuie utilizat numai pentru a planifica iterații. Compararea vitezelor echipei este o prostie, deoarece metrica se bazează pe estimări non-obiective. Tratarea vitezei ca măsură de succes este inadecvată și transformarea unei viteze specifice într-un obiectiv distorsionează valoarea acesteia pentru estimare și planificare.
• ratele de deschidere/închidere—câte probleme de producție sunt raportate și închise într-o anumită perioadă de timp. Tendința generală contează mai mult decât numerele specifice.

când oricare sau toate aceste valori sunt în afara intervalului așteptat sau în tendințe în direcții alarmante, nu vă asumați o cauză. Discutați cu echipa, obțineți întreaga poveste și lăsați echipa să decidă dacă există motive de îngrijorare și, dacă da, cum să o remediați.

nu puteți cunoaște sau presupune cauzele principale din numere, dar aceste valori vă oferă o perspectivă asupra locului în care procesele dvs. esențiale au nevoie de atenție. O rată ridicată de deschidere și o rată scăzută de închidere în câteva iterații, de exemplu, poate însemna că problemele de producție sunt în prezent o prioritate mai mică decât noile caracteristici sau poate că echipa se concentrează pe reducerea datoriei tehnice pentru a remedia clase întregi de probleme sau că singura persoană care știa cum să le remedieze renunță sau altceva. Nu puteți cunoaște sau presupune cauzele profunde din numere.

analiza producției

• timp mediu între defecțiuni (MTBF)
• timp mediu pentru recuperare/reparare (MTTR)

ambele sunt măsuri generale ale performanței sistemului software în mediul său actual de producție.

• rata de blocare a aplicației—de câte ori o aplicație eșuează împărțită la câte ori a fost utilizată. Această valoare este legată de MTBF și MTTR.

rețineți că niciuna dintre aceste trei valori nu vă spune despre caracteristicile individuale sau utilizatorii afectați. Cu toate acestea, cu cât numerele sunt mai mici, cu atât mai bine. Software-ul modern de monitorizare a operațiunilor face destul de ușoară colectarea unor valori detaliate privind programele și tranzacțiile individuale, dar este nevoie de timp și gândire atentă pentru a configura intervale adecvate pentru alerte și/sau declanșatoare pentru scalarea în sus sau în jos (pentru sistemele bazate pe cloud).

am dori ca software-ul nostru să nu eșueze niciodată, dar acest lucru este improbabil din punct de vedere statistic. Când software-ul nostru eșuează, ne-ar plăcea să nu piardă niciodată date critice și să se recupereze instantaneu, dar acest lucru poate fi extraordinar de dificil de realizat. Cu toate acestea, dacă software-ul dvs. este sursa dvs. de venit, efortul merită.

dincolo de MTBF și MTTR, măsurătorile cu granulație fină se bazează pe tranzacții individuale, aplicații și așa mai departe și reflectă valoarea afacerii livrate și costul remedierii defecțiunilor. Dacă aplicația dvs. de procesare a tranzacțiilor se blochează o dată la o sută, dar se recuperează într-o secundă sau două și nu pierde nicio informație critică, rata de blocare de 1% poate fi suficient de bună. Dar dacă fiecare accident este al unei aplicații care rulează 100.000 de tranzacții pe zi, pierde o vânzare de 100 USD și costă 50 USD pentru a remedia pe partea din spate, acea rată de blocare de 1% va fi o prioritate. Fixarea acestuia va avea un impact semnificativ asupra liniei de jos.

valori de securitate

Securitatea este un aspect al calității software-ului care este adesea trecut cu vederea până mai târziu (sau prea târziu). Instrumentele de analiză a securității pot fi utilizate în procesul de construire, pe lângă evaluări mai specializate și teste de stres. Cerințele de securitate sunt adesea simple și de bun simț, dar echipa de dezvoltare software trebuie să fie atentă la ele și la valorile derivate din acestea.

gama completă de practici de securitate și valori conexe depășește domeniul de aplicare al acestui articol, dar, la fel ca în cazul valorilor de proces agile și al valorilor de producție, există câteva valori specifice care pot însemna mult pentru satisfacția generală a clienților dvs.

• incidente Endpoint—câte puncte finale (dispozitive mobile, stații de lucru etc.) au experimentat o infecție cu virus într-o anumită perioadă de timp?
• MTTR (mean time to repair)—în valorile de securitate, Acesta este timpul dintre descoperirea unei breșe de securitate și o remediere funcțională desfășurată. Ca și în cazul metricii MTTR de producție menționate mai sus, MTTR de securitate trebuie urmărit pe intervale de timp specifice. Dacă valoarea MTTR crește în timp, atunci dezvoltatorii devin din ce în ce mai eficienți în înțelegerea problemelor de securitate, cum ar fi erorile și modul de remediere a acestora.

pentru ambele valori, numerele mai mici în timp înseamnă că vă deplasați în direcția corectă. Mai puține incidente punct final vorbește de la sine. Pe măsură ce valoarea MTTR scade, dezvoltatorii devin din ce în ce mai eficienți în înțelegerea problemelor de securitate, cum ar fi erorile și modul de remediere a acestora.

puteți găsi mai multe modalități de a aplica valori de securitate la dezvoltarea de software în articole securitatea aplicațiilor pentru proiecte Agile și modele de amenințări la adresa securității: o introducere agilă.

o notă privind valorile codului sursă

astăzi este ușor să conectați un scaner de cod sursă în conducta dvs. de construire și să produceți valori obiective. Există medii empirice și intervale sugerate și argumente logice cu privire la importanța relativă a acestor valori. Dar, în practică, aceste instrumente sunt cele mai utile în aplicarea stilurilor de codificare, marcarea anumitor anti-modele și identificarea valorilor și tendințelor aberante.

nu merită să te agăți de numere. Iată un exemplu, cu titlu de explicație.

să presupunem că găsiți o metodă într-o clasă cu o metrică ridicolă, cum ar fi o complexitate NPATH de 52 de milioane. Asta înseamnă că ar fi nevoie de 52 de milioane de cazuri de testare pentru a exercita pe deplin fiecare cale prin cod. Ai putea refactor codul într-o structură mai simplă, dar înainte de a face asta, ia în considerare ceea ce ar fi impactul de afaceri. Șansele sunt că vechiul cod urât funcționează suficient de bine (deși acoperirea testului poate fi inadecvată). Apelarea anti-modelului către echipă, astfel încât să poată evita repetarea acestuia, este o învățare valoroasă, dar fixarea acestuia probabil că nu ar muta acul pe nicio măsură de afaceri relevantă.

este cel mai bine dacă echipa este de acord cu nivelul de Conformitate și regulile la care este supus codul lor, dar să fie conștienți de faptul că examinarea valorilor aberante și obtinerea preocupat de blips tendință poate pierde o mulțime de timp.

apoi pune totul împreună: Succesul este metrica finală

bucuria utilizării instrumentelor automate pentru urmărirea și măsurarea valorilor de calitate și a analizelor utilizatorilor este că eliberează timp pentru a se concentra pe valorile care contează cu adevărat: valorile de succes.

cum se utilizează valorile pentru succes

întreprinderile au obiective. Obiectivele implică întrebări, cum ar fi „cum arată succesul?”sau” cum va afecta acest lucru comportamentul clienților?”Întrebările corect cuantificate implică valori.

altfel spus, valorile ar trebui folosite doar pentru a răspunde la întrebări, pentru a testa ipoteze care susțin un anumit obiectiv de afaceri. Și acest lucru ar trebui făcut numai atâta timp cât întrebările și răspunsurile ajută la schimbări pozitive.

acum, nu toate proiectele în general au un set de obiective, întrebări și ipoteze invariante și, prin urmare, valori?

Da, dar numai din punctul de vedere al afacerii. Măsurile la nivel de afaceri ale unor lucruri precum implicarea utilizatorilor, ratele apropiate, generarea de venituri și așa mai departe oferă feedback cu privire la modul în care se desfășoară afacerea în lumea reală. Modificările aduse software-ului care afectează afacerea vor afecta, de asemenea, aceste tipuri de valori.

la un nivel mai fin de rezoluție, fiecare caracteristică și poveste de utilizator poate avea propria metrică de succes—de preferință doar una și una care este direct legată de o măsură a valorii livrate clientului. Completarea a nouă din zece povești într-un sprint pentru funcții care nu sunt livrate niciodată este risipă, nu succes. Furnizarea de povești pe care clienții nu le doresc sau nu le folosesc este risipă, nu succes. Furnizarea unei povești care îmbunătățește un aspect al fericirii utilizatorilor este un succes. Furnizarea unei povești care, în mod demonstrabil, nu îmbunătățește implicarea utilizatorilor este, de asemenea, un succes, deoarece veți fi învățat ceva care nu a funcționat, ați invalidat o ipoteză de afaceri și ați eliberat resurse pentru a urmări alte căi.

cum se formulează o ipoteză de valoare

o ipoteză de valoare este o afirmație despre ceea ce credeți că se va întâmpla ca urmare a livrării unei caracteristici specifice. Relația dintre software, rezultatul dorit și valorile formează ipoteza valorii pentru caracteristică (sau sistem, sau poveste, sau upgrade etc.). Ipoteza ar trebui să exprime modul în care se așteaptă ca metrica vizată să se schimbe, în ce interval de timp și în ce măsură să fie considerată eficientă. Va trebui să discutați cu echipa și proprietarul produsului, cel puțin, pentru a afla lucrul specific pe care această caracteristică sau poveste este destinat să îl creeze sau să îl îmbunătățească în ceea ce privește afacerea pentru a-și formula ipoteza valorii. Este posibil să trebuiască să întrebați „de ce” de câteva ori (ca un copil de trei ani) pentru a dezlipi straturile de presupuneri nedeclarate; aveți răbdare. Când înțelegeți care ar trebui să fie valoarea afacerii, puteți începe să puneți întrebările care vă vor conduce la valorile care răspund la întrebare.

de exemplu, o poveste „tehnică” pentru a îmbunătăți viteza unui proces de verificare a comerțului electronic poate avea ca bază presupunerea că o verificare mai rapidă va duce la mai multe vânzări. Dar de ce credem asta? Sunt o mulțime de oameni abandonarea lor cărucioare de cumpărături în timpul procesului de checkout? Dacă acesta este consensul (deoarece acest consens este susținut de datele de bază), atunci ipoteza valorii poate fi „credem că un proces mai rapid de plată va duce la scăderea ratelor de abandon a coșului, ducând la vânzări mai mari și la o experiență îmbunătățită a utilizatorului.”

probabil că puteți presupune că utilizatorii vor dori o verificare mai rapidă, dar nu strică să întrebați dacă au observat. Ratele de abandonare a coșului și vânzările pot fi măsurate înainte și după ce noul proces este în vigoare, pentru o perioadă de timp. Dacă rata de abandon a coșului scade și vânzările cresc (dincolo de fluctuațiile statistice), dovezile susțin ipoteza și s-ar putea să luați în considerare dacă sunt justificate și alte îmbunătățiri ale vitezei. Dacă nu, lăsați această valoare să se estompeze în fundal (sau eliminați-o, dacă vă distrage atenția) și îndreptați-vă atenția către următoarea ipoteză. Dacă rata de abandonare a coșului scade, dar vânzările sunt neschimbate, măsurați pentru o perioadă mai lungă de timp sau regândiți legătura presupusă între abandonarea coșului și vânzări. Cu alte cuvinte, folosiți valori pentru a învăța și numai atâta timp cât se dovedesc utile pentru îmbunătățirea conducerii.

în unele cazuri, ipoteza poate fi în mod clar greșită, așa că renunțăm la valori (și anulăm modificările software-ului!) după câteva zile. În alte cazuri, ipoteza poate fi corectă, așa că continuăm să aducem îmbunătățiri în acest domeniu de ani de zile.

șase euristici pentru utilizarea eficientă a valorilor

am văzut cum valorile subiective ale software-ului contează mult mai mult pentru succesul afacerii decât valorile tradiționale și obiective ale calității vechi. Efortul necesar pentru a găsi și măsura valorile de afaceri relevante pentru caracteristici este compensat de perspectivele și oportunitățile de învățare câștigate. Condițiile și oportunitățile de afaceri se schimbă constant, așa că, mai degrabă decât să rezumăm o formulă de urmat, care poate fi fragilă, iată șase reguli generale, sau euristică, pentru a ajuta la menținerea concentrării și flexibilității. Fie ca acestea să vă ajute să vă ghideze în călătoria dvs. către software de calitate și succes în afaceri!

1. metricile nu vă pot spune povestea; numai echipa poate face acest lucru (cu un sfat de pălărie pentru Todd DeCapula).
2. Compararea fulgilor de zăpadă este deșeuri.
3. puteți măsura aproape orice, dar nu puteți fi atenți la toate.
4. valorile succesului în afaceri conduc la îmbunătățiri ale software-ului, nu invers.
5. fiecare caracteristică adaugă valoare; fie măsurați-o, fie nu o faceți.
6. măsoară doar ceea ce contează acum.