Cele mai bune cinci KPI-uri de inginerie software și cum sunt înșelate

De Bill Harding,Programator/CEO
Publicat la 31 martie 2020.Ultima actualizare la 17 aprilie 2020.

Când oamenii vorbesc despre KPI-uri de inginerie, există două truisme contradictorii pe care le auzi adesea:

Ceea ce este măsurat se îmbunătățește.-Peter Drucker

Și

Când o măsură devine o țintă, încetează să mai fie o măsură bună.

Când o măsură devine o țintă, încetează să mai fie o măsură bună.Legea lui Goodhart

Ambele afirmații descriu în parte KPI-urile inginerești, dar luate împreună implică faptul că este simposibil să se folosească măsurarea pentru a se îmbunătăți. Cum poate un manager axat pe date să acopere acest decalaj?

Veștile proaste sunt că este nevoie de un anumit angajament pentru a învăța, în special pentru cei care provin din roluri îndepărtate (adică non-tehnice). vestea bună este că măsurătorile alese cu grijă pot și continuă să funcționeze în ciuda faptului că „devin o țintă”. De fapt, pentru mulți dintre parametrii pe care îi vom recomanda, cu cât un angajat „joacă mai mult cu sistemul”, cu atât interesele pe termen lung ale afacerii sunt mai bine servite. Scopul final este ca metricile să continue să funcționeze în timp ce sunt „jucate”. Existăcinci măsurători care îndeplinesc acest criteriu.

Publicul țintă: Manager cu spirit de acțiune

Care manager care a încercat să smulgă mai multe tichete finalizate de la echipa sa de ingineri cunoaște lupta. ei vor să ia măsuri corecte, susținute de date, care să le îmbunătățească viteza. Ei știu că luarea deciziilor pe baza instinctelor este costisitoare și nescalabilă. Cu toate acestea, când se uită la lista lor de lucruri de făcut, aceasta este plină de sarcini care par mai presante decât „îmbunătățirea măsurătorilor”. În practică, îmbrățișarea măsurării se întâmplă adesea după un eșec catastrofal, cum ar fi un build de lansare cu bug-uri sau observarea faptului că un dezvoltator nu a închis niciun bilet într-o lună.

Inclusiv atunci când este clar că trebuie să se facă măsurători, este ambiguu de unde să începi. Puteți căuta pe Google „engineering KPIs”, să dați clic pe întreaga primă pagină de rezultate și să rămâneți neclar cu privire la următorii pași de făcut. Luați ca exemplu metrica „Team Velocity” (Viteza echipei), adesea invocată. Aproape toate rezultatele de pe Google recomandă măsurarea „Vitezei echipei”, dar nimeni nu vrea să spună dacă aceasta este măsurată în… bilete închise? Linii de cod? Puncte de poveste? Orice ar fi, managerii nu au timp să își dea seama. Ei au nevoie să coboare de la acest munte de teorie de 15.000 de picioare în ceva ce pot înțelege, în care pot avea încredere și de care pot beneficia… de preferință imediat.

Primisa organizatorică a acestui articol este că sunteți un manager care dorește să înțeleagă suficient de bine metrica ingineriei software pentru a-și face echipa mai eficientă. Fiind manager înseamnă că sunteți prea ocupat pentru a învăța despre teorie, cu excepția cazului în care aceasta se leagă direct de modul în care puteți beneficia de acea teorie.

Metricile trebuie să fie practice pentru ca afacerile reale să le încerce

Înainte de a scrie acest articol, am digerat metricile propuse de primele 20 de rezultate Google în domeniul metricilor software. După cum v-ați putea imagina, fiecare sursă a avut propriile teorii cu privire la metricile care contează cel mai mult. articolele lor au grupat adesea metricile în grupe precum „metricile de proces” și „metricile de proiect”. Vom urma indicația lor cu privire la gruparea metricilor, dar grupurile noastre vor fi „metrici de calitate” și „orice altceva.”

Iată ce se califică drept o metrică de calitate:

  • Valoare de afaceri.Este posibil să tragem o linie dreaptă de la metrica => valoare de afaceri creată?
  • Măsurabilă.Putem defini un număr specific și unitățile sale de măsură (de ex, puncte, procente), astfel încât să poată fi urmărit în timpși corelat cu evenimente și experimente?
  • Acționabil.Poate informa în mod regulat acțiuni care să conducă la rezultate pozitive? De preferință cu un număr minim de falsuri pozitive?
  • Disponibil/convenient.Poate o echipă medie de inginerie software să aibă acces la această măsurătoare fără a-și modifica procesele de dezvoltare existente?
  • Popular.Are suficient de mulți adepți pentru a fi bine documentată și credibilă?
  • Includerea în găleata „Măsurători de calitate” necesită toate cele cinci de mai sus, plus un răspuns satisfăcător la întrebarea noastră de răscruce: dacă avem încredere în această măsurătoare, iar dezvoltatorii optimizează ulterior pentru ea, ce se întâmplă apoi?În anii petrecuți în construirea și iterația propriei noastre măsurători de dezvoltare („Line Impact”), am învățat că produsele secundare toxice sunt o consecință așteptată a măsurării, cu excepția cazului în care măsurarea este aliniată cu precizie la valoarea de afaceri pe termen lung.Ca exemplu, vom arăta mai târziu cumdezvoltatorii care încearcă să se joace cu metrica „Lead Time” cauzează o transparență redusă pentru management.

    KPI de inginerie de calitate

    Iată cinci metrici software care verifică toate căsuțele pentru a ajuta managerii să conducă o echipă mai eficientă.

    🏦 OKR-driven

    Exemplu de șablon OKR

    Unul dintre multele exemple de șabloane OKR disponibile prin intermediul Weekdone la Okrexamples.com

    Orice listă care se concentrează pe maximizarea valorii de afaceri ar trebui să înceapă aici. Companii de frunte precum Google folosesc OKRca o axă principală pe care să evalueze inginerii seniori. Dezavantajul măsurătorilor bazate pe OKR este că acestea sunt, prin definiție, specifice particularităților afacerii. Acest lucru face imposibilă generalizarea unei formule prin care să le capturăm, sau generalizarea căii prin care acestea vor fi jucate.

    Cum să le jucăm?Riscul ca OKR-urile să fie jucate este scăzut, deoarece acestea sunt de obicei centrate pe afaceri. Principalul pericol al măsurătorilor bazate pe OKR-uri este că, din moment ce sunt de obicei formulate o singură dată (sau periodic), acestea sunt poate mai puțin fiabile decât cele care au fost verificate de-a lungul anilor. Întotdeauna sunt posibile cazuri limită care stau la pândă.De exemplu, stabilirea unui OKR pentru „introducerea a mai puțin de 10 erori pe lună” ar putea fi manipulată prin faptul că nu se lansează nicio caracteristică nouă. Presupunând că ambele părți acționează cu bună credință, în practică, jocurile OKR ar trebui să fie rare.

    Cum se obține?Prin intermediul tablourilor de bord de măsurare existente sau prin colaborarea cu companii precumWeekdone care ajută la furnizarea de inspirație OKR.

    📐Line Impact

    Exemplu de KPI de inginerie Line Impact: metrică de încredere pentru codul sursă

    10 depozite reprezentate grafic după Line Impact, o metrică ce cuantifică ritmul în care evoluează codul sursă,imagine mulțumită GitClear

    Line Impact este o metrică concepută să măsoare câtă energie cognitivă este investită în dezvoltarea de software.Acest videoclip oferă o explicație ilustrată a modului în care acest lucru este posibil. Explicația pe scurt este că Line Impact anulează toată activitatea interstițială („churn”) care are loc atunci când o caracteristică este dezvoltată, lăsând o întruchipare concentrată a muncii care a avut loc. Line Impact este conservatîntre limbaje, astfel încât este nevoie de o cantitate de timp constantă pentru a genera Line Impact, indiferent dacă dezvoltatorul scrie Java, Python, Javascript sau orice alt limbaj de programare important (peste 30 de limbaje acceptate).

    În ceea ce privește valoarea comercială, Line Impact este paralel cu Story Points: ilustrează modul în care costul unei sarcini fluctuează în funcție de dezvoltatorul căruia îi este atribuită. Pornind de aici, un manager angajat poate folosi raportul Domain Expertspentru a potrivi Jiras cu experții în domeniu, ceea ce poate accelera dramatic viteza produsului.

    Cum să o joci?Orice măsurătoare care pretinde „Lines of Code” (LoC) ca sursă de date (așa cum face Line Impact) merită să fie abordată cu prudență. Implementate neglijent,imperfecțiunile subtile în procesare sunt amplificate într-un zgomot care estompează semnalul.De aceea, GitClear a construit cele mai bune instrumente de revizuire a codului de pe piață:astfel încât managerii și dezvoltatorii să poată revizui modul în care Line Impact este distribuit pe fiecare angajament, pe fiecare fișier.Transparența este un antidot puternic pentru a combate jocul.

    O protecție suplimentară vine sub forma unor notificări care se declanșează atunci când un dezvoltator contribuie cu muncă la o viteză neobișnuită. Aceste și alte măsuri au făcut ca Line Impact să fie suficient de dificil de jucat, încât GitClear nu a primit încă un client care să raporteze că Line Impact a fost jucat cu succes de echipa sa.Acestea fiind spuse, ar fi lipsit de onestitate să pretindem că metrica este cumva impenetrabilă la jocuri, așa că iată o listă de căi cunoscute prin care se poate acumula rapid Line Impact.Esența este că dacă un dezvoltator scrie teste, șterge cod vechi și adaugă documentație, va câștiga o cotă neajuns de mare din Line Impact.

    Cum să o obțineți?Înscrieți-vă pentru o perioadă de încercare gratuită de 15 zile. Dacă vă place,prețurile pornesc de la 9 dolari pentru fiecare dezvoltator activ.Vedeți un scurt video explicativ despre Line Impact aici.Versiunea on premise este disponibilă.

    🎲 Story Points

    Copii de performanță în inginerie: Jira burndown report

    Raportul „release burndown” bazat pe Story Point, disponibil prin Jira

    Story Points ar putea pretinde că este cel mai „clasic” dintre KPI-urile de inginerie. Existămai multe moduri diferite de a calcula Story Points. Toate formele se raportează la o estimare a timpului estimat al dezvoltatorului pentru a finaliza o anumită sarcină. Managerii pot folosi Story Points pentru a calcula costurile pe care le implică o sarcină, de exemplu, dacă un dezvoltator câștigă 10.000 $/lună, iar biletul este estimat la 10 Story Points = jumătate de lună, atunci costul este de 10.000 $ * 0,5 = 5.000 $.Folosind o versiune a acestui calcul ajută la prioritizarea sarcinilor pe baza celor care produc cel mai mare raport dintre valoarea proiectată și costul de implementare proiectat.

    Cum se joacă?Cea mai mare atenție aici aparține modului în care se calculează Story Points. Cel mai simplu mod de a „juca” Story Pointseste ca echipa de dezvoltatori să influențeze scala de evaluare, de obicei în sensul supraestimării dificultății. O opțiune pentru a rezolva această problemă este de a permite ca sarcinile să fie selectate într-o „piață de sarcini”, unde sarcinile supraevaluate pot fi distribuite în mod egal între dezvoltatori pentru a menține o calibrare relativă. O altă modalitate de a aborda acest aspect este recalibrarea periodică a constantei utilizate pentru a transforma punctele de poveste în „zile de dezvoltare”. Rețineți că, din moment ce implementarea Story Points diferă adesea în funcție de echipă, nu este recomandabil să le folosiți pentru a compara performanțele între echipe.

    Cum se obține?Aproape orice sistem de urmărire a problemelor din această parte a GitHub permite specificarea Story Points. În ceea ce privește vizualizarea lor, Jiraoferă un „next-gen velocity report „dedicat scopului de a arăta Story Points finalizate în timp.Ei oferă, de asemenea, un „release burndown report” care folosește Story Points pentru a estima modul în care echipa se îndreaptă spre obiectivele lor pentru sprint. GitClear oferă, de asemenea, grafice rudimentare (deocamdată) care ilustrează Story Pointscompletate în timp.

    🐞 Rata de erori / Defecte scăpate

    Acest parametru este definit în diferite moduri de diferite surse, dar toate ajung la aceeași întrebare esențială: câte erori ajung în lume și cât de bine răspundem la ele?Stackify o relatează în termeni numerici specifici:

    Rata de scăpare a defectelor este exprimată ca un procent bazat pe câte defecte găsiți înainte ca acestea să ajungă în producție sau câte ajung în producție, cum preferați. Fiecare proiect software și fiecare echipă va fi diferită, dar noi sugerăm să ne străduim să găsim 90% din toate defectele înainte ca acestea să ajungă în producție.

    Definiția Stackify face presupunerea că cineva va desemna un câmp în trackerul lor de problemepentru a capta în ce fază de dezvoltare a apărut bug-ul. Pentru echipele care nu au timp să configureze și să urmărească fazele de dezvoltare, o definiție înlocuitoare poate fi:

    Cât de des codul scris într-o nouă caracteristică devine cod modificat în cursul rezolvării unui bug?

    Un răspuns legat de date la această întrebare este furnizat utilizatorilor GitClear, dar este dificil de calculat manual (dacă nu sunteți utilizator GitClear).O măsură de rezervă, disponibilă în mod garantat, a ratei de apariție a bug-urilor poate fi „care este raportul dintre bug-urile create și bug-urile rezolvate”?

    Cum să o joci?Această măsură este dificil de jucat. Un dezvoltator poate prelua mai multe tichete mici, dar fiecare tichet introduce un risc incremental de bug-uri dacă nu este atent. Acest risc al utilizării ratei de erori este că are nevoie de o contrabalansare pentru „progres”, cum ar fi Story Points sau Line Impact, altfel un dezvoltator ar putea să zăbovească asupra unei singure probleme pentru tot sprintul, asigurând o rată de erori de 0%.

    Cum să o obțineți?Dacă echipa dvs. are lățimea de bandă pentru a eticheta problemele în funcție de faza de dezvoltare în care au apărut, atunciEscaped Defects poate fi calculată manual prin intermediul oricărui tracker de probleme. GitClear este o altă opțiune disponibilăpentru a calcula procentul de caracteristici care devin bug-uri.

    ✅ Pull Request Completion Rate

    Exemplu de KPI ingineresc Pull Requests: statistici pe GitClear

    Un eșantion de statistici ale pull request-urilor furnizate de GitClear

    Ce procent de pull request-uri au fost închise în decurs de o săptămână de la deschidere? Acest lucru atrage mai multe întrebări mai granulare, cum ar fi „este echipa angajată în a răspunde prompt la noile cereri de extragere”, „sunt capabili să coopereze” și „dezvoltatorii și-au șlefuit codul înainte de a-l trimite pentru fuziune?”

    Cum se joacă?Atingerea testului „Pull request completion rate” înseamnă să închizi întotdeauna PR-urile în decurs de o săptămână. Acest lucru este relativ greu de jucat, dar trebuie să fie contrabalansat de o forță de propulsie, cum ar fi Story Points sau Line Impact, altfeltoate stimulentele echipei vor fi de a lustrui munca mai degrabă decât de a o expedia (sau de a o supune revizuirii PR).

    Cum să o obțineți?Toți furnizorii de „nume de marcă” Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) oferă statistici care ilustrează eficiența procesului de pull request al unei echipe. ajutăm la compararea furnizorilor aici.

    Mențiuni onorabile

    Dedesubtul indicatorilor de „top tier”, găsim un nivel interstițial. Aceștia sunt metrici care posedă caracteristici dezirabile alături de neajunsuri importante. Ele pot oferi în continuare valoare, atâta timp cât un manager știe suficient pentru a ține cont de limitările lor.

    Lead Time/Cycle Time

    Graficul Lead Time așa cum este vizualizat prin Azure Devops

    În timp ce este listat (de două ori!) înPluralsight’s list of Top 5 Metrics,Cycle Time este o idee bună care este foarte susceptibilă la jocuri de noroc.

    „Lead Time” este cel mai adesea definit ca „Care este intervalul dintre momentul în care o sarcină este depusă în issue trackerși momentul în care este livrată clientului?”. Vărul său, „Cycle Time”, este un subansamblu al Lead Time, definit ca fiind „intervalul de timp dintre momentul în care echipa de produs l-a scos din coada de așteptare și momentul în care a ajuns în producție.”

    Cum se poate juca?Performanța Lead Time depinde într-o anumită măsură de mecanismul prin care sunt depuse Jiras, ceea ce înseamnă că aplicabilitatea sa între echipe este scăzută. Cycle Time depinde de convențiile prin care comitentul alege să facă prima sa confirmare. Astfel, această măsurătoare este ușor de jucat dacă un dezvoltator își salvează la nivel local angajamentele și le eliberează într-o singură tranșă de lucru imediat înainte de a depune PR-ul. Acest eșec este motivul pentru care Cycle Time este relegat în secțiunea „Mențiuni onorabile”. De asemenea, nu este ideal: prin stimularea unui dezvoltator de a-și salva angajamentele fără a le împinge, este imposibil pentru colegii de echipă să intervină în timp ce munca este în desfășurare.Acest efect secundar reduce transparența dintre un manager și dezvoltatorii săi.

    Cum se obține?Azure Devops Services oferă graficul prezentat mai sus.Jira oferă, de asemenea, o versiune a acestuia.Toate ofertele majore de Inginerie Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementează o anumită versiune de calcul al timpului de execuție.

    Acoperirea testelor

    Încercarea de a capta o anumită măsură a acoperirii testelor este un obiectiv rezonabil de luat în considerare pentru a urmări. Cu toate acestea, nu prea reușește să se impună ca o măsură de Top Tier din două motive:

  1. Este o soluție incompletă. Testarea adecvată trebuie să includă teste funcționale și de integrare alături de testele unitare și nicio soluție automatizată nu poate ști ce pagini trebuie vizitate în cadrul aplicației sau al site-ului web, acest lucru necesită în continuare o direcție umană
  2. Este foarte dificil de legat la parametrii de afaceri de top. Acoperirea testelor merită să fie evaluată ca parte a planului unui dezvoltator principal pentru a monitoriza calitatea codului, dar nu se leagă suficient de direct de valoarea afacerii pentru a fi luată în considerare de una singură. O metrică înrudită, dar mai funcțională pentru afaceri, pentru a urmări defectele de cod este „Bug Rate / Escaped Defects.”

„Everything Else” Metrics

Lista de mai sus este relativ scurtă în comparație cu corpus-ul de metrici din trecut care au fost propuse de alți autori.De dragul completitudinii, să trecem în revistă unii dintre cei mai frecvent menționați parametri menționați în altă parte și de ce nu au fost selectați.

Team Velocity

Aceasta a fost unul dintre cei mai populari parametri citați de alte articole. Este recomandată deTechBeacon,InfoPulse șiSeaLights.io.Cu toate acestea, autorii par să se ferească să definească unitățile acestei importante măsurători.TechBeacon o definește ca fiind „câte „unități” de software finalizează de obicei echipa într-o iterație”. Nu este sotangibil. InfoPulse nu încearcă să precizeze unitățile. SeaLights spune că unitățile sunt „Story Points”. Astfel, concluzionăm că noțiunea de „viteză” este captată în mod adecvat de Story Points, sau Line Impact prin proxy.

Code Churn

Directorul general al GitPrime (acum achiziționat de Pluralsight) a fost printre cei care au pledat pentru luarea în considerare a Code Churn.Noi susținem ca răspuns că implicațiile Code Churn sunt peste tot pe hartă, ceea ce face foarte dificil să se acționeze în cazul unui nivel ridicat de churn. Măsurătorile trebuie să fie acționabile.

Release/Sprint Burndown

SeaLights și InfoPulse recomandă să se acorde atenție modului în care o echipă tinde spre obiectivele de sprint.Suntem de acord că acest lucru este important, dar este deja acoperit de secțiunea „Story Points” de mai sus.

Timp mediu de reparare / Timp mediu între defecțiuni

Dintre cele câteva articole care susțin acești indicatori, niciunul nu se aventurează să descrie în ce unități se bazează indicatorul sau ce serviciu poate fi folosit pentru a aduna aceste puncte de date. cercetările descoperă că Atlassian oferă un articol de ajutor pe această temă. dacă acest articol nu ar avea deja 2.500 de cuvinte, MTTR ar putea intra în secțiunea „Mențiuni onorabile”. Dar nu este ușor de legat de valoarea de afaceri și nu este simplu de accesat de către o echipă medie fără a-și schimba rutina.

Am ratat ceva?

.

Leave a Reply

Lasă un răspuns

Adresa ta de email nu va fi publicată.