CodeGym /Blog Java /Aleatoriu /Măsuri de productivitate. Ce trebuie să știți despre măsu...
John Squirrels
Nivel
San Francisco

Măsuri de productivitate. Ce trebuie să știți despre măsurarea performanței în software?

Publicat în grup
Chiar dacă abilitățile practice și cunoștințele despre limbaje, instrumente și tehnologii specifice de programare sunt cheia pentru obținerea unui loc de muncă cu normă întreagă ca dezvoltator de software, există un alt indicator valoros care, în multe feluri, poate fi privit ca o presupoziție pentru succesul în această profesie: productivitate. Măsurarea productivității este ceva pe care toți dezvoltatorii de software profesioniști trebuie să înțeleagă și să ia în considerare, deoarece valorile de performanță sunt în mod inerent importante pentru orice echipă de dezvoltare de software în mediul de afaceri actual. Măsuri de productivitate.  Ce trebuie să știți despre măsurarea performanței în software?  - 1

De ce contează productivitatea ta ca dezvoltator?

În era dezvoltării Agile, DevOps și ciclurile de lansare software în scădere, când dezvoltatorii trebuie să livreze noi versiuni de produse cât mai repede posibil, companiile folosesc mai multe valori de productivitate diferite pentru a evalua performanța programatorilor individuali și a unei echipe în ansamblu. Privind acest lucru din punctul de vedere al unui dezvoltator, măsurarea performanței poate servi pentru o serie de scopuri valoroase, ajutându-vă să urmăriți progresul abilităților dvs. de programare, ceea ce v-ar permite să obțineți o creștere profesională consecventă. Codificatorii extrem de productivi sunt cei care ajung să primească oferte salariale uluitoare și se apucă de lucru la cele mai interesante proiecte. Dar chiar dacă nu sunteți chiar o persoană cu performanțe mari și doriți doar orice loc de muncă în dezvoltarea de software și să aveți un succes rezonabil în ea, mai trebuie să aveți cel puțin o înțelegere de bază a indicatorilor de performanță și a modului în care aceștia sunt utilizați pentru a măsura productivitatea input-ului dvs. la locul de muncă. Despre care vom vorbi astăzi.

Măsuri de măsurare a productivității dezvoltării software

Care sunt valorile productivității dezvoltării software?

Măsurile de dezvoltare software sunt domeniile activității de programare în care pot fi aplicate măsurători cantitative pentru a urmări performanța, calitatea muncii și productivitatea unui dezvoltator. Fiecare măsură de productivitate se bazează pe preluarea datelor din procesul de dezvoltare și utilizarea acestora pentru a măsura productivitatea. Deoarece aproape nimic legat de dezvoltarea de software nu este ușor și direct, ați putea spune că măsurarea productivității programării este, de asemenea, destul de inconsecventă și fragmentată în industrie. Sau, pur și simplu, diferite echipe și companii pot folosi indicatori de performanță complet diferiți și pot aborda această problemă din mai multe unghiuri. Deci, nu trebuie să vă deranjați să învățați fiecare măsurătoare care poate fi utilizată de echipele de dezvoltare software.

Ce tipuri de metrici de productivitate pentru dezvoltarea de software există?

Desigur, există mai multe valori de productivitate diferite care abordează măsurarea performanței pe diferite niveluri și unghiuri. Iată cele mai comune tipuri de astfel de valori de productivitate:

  • Valori formale axate pe dimensiune.

Aceste metrici sunt axate pe măsurarea dimensiunii rezultatului muncii unui programator, cum ar fi liniile de cod (LOC), lungimea instrucțiunilor de cod, complexitatea codului, etc. Aceste metrici sunt din ce în ce mai considerate a fi învechite în industria de dezvoltare software de astăzi.

  • Măsuri de productivitate centrate pe timp și pe funcție.

Există o selecție de metrici tradiționale de productivitate utilizate în dezvoltarea software-ului în cascadă, cum ar fi zilele active, domeniul de aplicare al funcționalității livrate într-o perioadă de timp stabilită, ratele de pierdere a codului, numărul de sarcini atribuite etc.

  • Măsuri ale procesului de dezvoltare agilă.

Măsurile procesului de dezvoltare agilă, cum ar fi raportul de ardere a sprintului, viteza, timpul de pregătire, timpul de ciclu și altele, sunt probabil cele mai frecvent utilizate valori de echipele de dezvoltare de software astăzi. Despre metricile Agile vom vorbi mai detaliat mai târziu în articol.

  • Măsuri de analiză operațională.

Acest set de valori se concentrează pe măsurarea performanței software-ului în mediul său de producție actual. Timpul mediu dintre erori (MTBF), timpul mediu de recuperare (MTTR) și rata de blocare a aplicației sunt cele mai utilizate valori aici.

  • Testarea valorilor.

Testarea software-ului are propriul set de metrici pentru a măsura calitatea testării sistemului, cum ar fi procentul de teste automate, acoperirea codului etc.

  • Indicatori de satisfacție a clienților.

În cele din urmă, valoarea finală pentru orice produs de software este experiența clientului final și există un întreg set de valori și pentru asta, cum ar fi scorul efortului clienților (CES), scorul de satisfacție a clienților (CSAT), scorul net al promotorului (NPS) si altii.

Măsuri de dezvoltare software agile

După cum puteți vedea, este destul de ușor să vă pierdeți în toate complexitățile parametrilor de productivitate software. Singurele cu care un dezvoltator de software obișnuit ar trebui să fie bine familiarizat, totuși, sunt metricile Agile, utilizate în mod obișnuit de echipele de dezvoltare de software astăzi ca standarde de măsurare a productivității echipei în diferite părți ale ciclului de viață al dezvoltării software. Să enumerăm principalele și cele mai frecvent utilizate valori Agile.

1. Sprint Burndown.

Rapoartele Sprint Burndown sunt una dintre valorile cheie pentru echipele agile de dezvoltare scrum. Deoarece în agil procesul de dezvoltare este organizat prin sprinturi limitate în timp, Sprint Burndown este folosit ca o modalitate de a urmări finalizarea sarcinilor în timpul unui sprint. Orele sau punctele de poveste sunt folosite ca unitate de măsură. Scopul este de a realiza un progres constant și de a livra munca în conformitate cu proiecțiile inițiale. Sprint Burndown ajută echipele să măsoare ritmul de lucru și să-l ajusteze atunci când este necesar.

2. Viteza echipei.

Viteza este un alt indicator cheie, care se bazează și pe ore sau puncte de poveste ca unitate de măsură. Măsoară cantitatea medie de muncă pe care o echipă o completează în timpul unui sprint și este utilizat pentru estimare și planificare pe tot parcursul proiectului. Viteza de urmărire este importantă pentru a vă asigura că echipa oferă performanțe consistente.

3. Puncte de poveste.

La nivelul unui membru al echipei de dezvoltare individuală, punctele de poveste sunt o măsură valoroasă, deoarece dimensiunea poveștilor livrate de un programator în timpul fiecărei lansări este un indicator al productivității acestui programator.

4. Diagrama de control al ciclului.

Măsoară timpul total din momentul în care a început munca la o sarcină sau la un alt element în restanță până la finalizarea acestuia. Permite urmărirea și controlul timpilor de ciclu, oferind rezultate mai previzibile.

5. Debitul și valoarea furnizată.

Managerii de proiect analizează sarcinile atribuite dezvoltatorilor și le atribuie valoare. Această măsurătoare este apoi utilizată pentru a măsura randamentul echipei sau, cu alte cuvinte, cantitatea de muncă cu valoare adăugată efectuată.

6. Cod Churn.

Code churn este o altă măsură care merită menționată, deoarece este folosită atât pentru măsurarea productivității unei echipe în ansamblu, cât și pentru a urmări performanța programatorilor individuali. Code churn măsoară cât de des un dezvoltator elimină sau face modificări în liniile de cod adăugate anterior și ce procent din codul scris anterior ajunge să fie schimbat sau aruncat.

Opiniile experților

În cele din urmă, pentru a adăuga o perspectivă, câteva citate pe această temă de către profesioniști cu experiență în industria de dezvoltare de software. „Sper că nu căutați să vă „comparați” valorile cu un fel de standard sau chiar cu performanța unei alte echipe dintr-o altă companie. Oriunde am lucrat, au avut variații unice în definițiile lor ale punctelor de poveste, vitezei, estimărilor orare, sarcinilor etc., care ar face într-adevăr aproape imposibilă compararea performanței unei echipe dintr-o companie direct cu cea a altei echipe din alta. companie”, a remarcat Cliff Gilley, fost manager tehnic de produs și antrenor Agile. „Sunt un pic nedumerit în ceea ce privește valorile când vine vorba de ghidarea performanței echipei. Odată ce acordați atenție doar uneia sau două variabile, devine foarte ușor să vă încadrați (intenționat sau altfel) în jocul valorii și să vă păcăliți că vă îmbunătățiți - când tot ceea ce faceți este să îmbunătățiți metrica. De exemplu, valorile bazate pe viteză se pot „îmbunătăți” prin trecerea echipei la povești mai mici (mai puțină muncă per poveste – deci mai multe povești finalizate – astfel încât viteza crește). Acesta ar putea fi un lucru bun dacă poveștile sunt povești utile pentru utilizatori, care oferă creșteri mai mici ale valorii afacerii. Acesta ar putea fi un lucru rău dacă poveștile devin sarcini mai mici și mai „tehnice” care nu oferă o valoare reală de la sine”, a spus Adrian Howard, un alt profesionist din industrie.. „Când lucrez într-un sistem bazat pe tragere, prețuiesc randamentul și timpul de ciclu. Primul îmi oferă informații generale despre capacitatea echipei noastre și, în timp, poate deveni o măsură predictivă foarte puternică. Al doilea este util ca un indicator general al eficienței conductelor noastre. Dacă timpul ciclului este mare, este timpul să începem să ne uităm la conductă, pentru că există o constrângere pe care probabil că putem lucra spre relaxare/exploatare. Dar valorile sunt doar instrumente. Nu vă pierdeți în ele și, cu siguranță, nu începeți să planificați pentru o anumită valoare. Gândește-te la ceea ce faci ca o echipă și la modul în care lucrezi în mod natural, apoi construiește sistemul în jurul oamenilor. Valorile ar trebui să vă ajute să vedeți cum sistemul dvs. sprijină munca tuturor. Sau nu”, a concluzionat Dave Cerra, un producător de dezvoltare de jocuri video .
Comentarii
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION