KPI pentru Echipe de Dezvoltare Software – Arragonán – Dani La Latorre

Ca parte a muncii mele În ultimul an, am încercat să împing cultura îmbunătățirii continue în diferite echipe cu care am lucrat . Ambele cu privire la problemele de instrumente tehnice și de competențe, cum ar fi cele de comunicare și coordonare, cu anumite restricții și dependențe care cad din marja de influență.

Începem de la presupunerea că ceea ce mai bine practicile echipei sunt, o mai bună capacitate de livrare va avea. Care se traduce într-o adaptabilitate mai mare la schimbări, o mai bună menținere a software-ului cu trecerea timpului și, eventual, o motivație mai mare a echipei cu munca sa.

Pe lângă senzațiile tipice subiective de îmbunătățire, A trebuit să ne gândim la indicatori care ne permit să o obținem cu adevărat. La un moment dat, ar începe să aibă și să aibă vizibilitate din afara echipelor, așa că a trebuit să mă întorc și să comand idei.

Am pregătit o prezentare pentru a explica intern cum lucrăm, unde am lucrat crezut că ar trebui să trecem printr-o îmbunătățire continuă, diferitele KPI pe care am putea observa și nevoile care ar fi acoperite cu o bună capacitate de livrare.

Glisați o prezentare cu Viziunea a ceea ce, ca o echipă ar trebui să fie acoperită: Adaptabilitate în ceea ce privește afacerea, livrarea în curând, evitând rework, un bun UX și evitarea bug-urilor pe cât posibil

„Spune-mi cum mă aduc și Îți voi spune cum mă comport „

Nu știu originea, dar cu aceste lucruri îmi amintesc întotdeauna această afirmație. Trebuie să mergi cu ochii cu ce indicatori (nu obiectiv) vom măsura . În plus, va trebui să folosim mai multe pentru a compensa promovarea comportamentelor ciudate care false acele valori.

cu utilizare Normal de instrumente, convenind doar câteva convenții, exploatarea ulterioară a datelor poate fi facilitată pentru a extrage valorile. Sursele de date pentru indicatori sunt:

  • codul
  • Depozitul de automatizare
  • Instrumentele de gestionare
  • Produsul însuși

Indicatori de cod

Instrumentele de analiză a codurilor statice ne oferă numere pe datoria tehnică care există. Nu ar trebui să pierdem din vedere acești indicatori și să dedicăm timp să analizăm și să facem o curățare specifică din când în când. Uneori sunt rezolvate cu soluții simple, iar altele ascund problemele de proiectare care nu sunt atât de evidente.

acoperirea de testare este unul dintre cei mai frecvenți indicatori, cel mai interesant în acest caz este de a vedea ceea ce nu este acoperit. Și așa cum este de obicei discutat, trebuie să mergem cu atenție deoarece este un indicator ușor de falsificat dacă este căutat ca o țintă.

la un moment dat, în plus, ar putea fi utilizate testarea mutației (verificați că un test este întrerupt la modificarea codului de producție) pentru a avea un indicator al calității testelor unității.

Indicatori de depozitare și server de automatizare

Există indicatori destul de interesanți care pot fi eliminați De la depozite și servere de automatizare, deși în cea mai mare parte depind de convențiile de utilizare.

Cu toate acestea, un indicator întotdeauna valabil și că cred că ar trebui respectat este frecvența de integrare.

Integrarea continuă este o practică (care nici un instrument) la fel de popular ca fiind interpretat greșit, deoarece până când lucrarea pe care ați făcut-o sau face o persoană cu filiala principală de dezvoltare și o construcție este finalizată, nu o facem.

Până când ați terminat corect Construcția unui artefact software, nu știm dacă totul este corect. Mai multă frecvență, feedback-ul mai devreme și mai puțin incertitudine.

În cazul utilizării ramurilor, este, de asemenea, interesant să vedem durata de viață a ramurilor. Mai mult timp, risc crescut de conflicte sau alte probleme atunci când se integrează.

și dacă se utilizează cereri de tragere / îmbinare, există, de asemenea, o mână de indicatori care, în orice moment, pot scoate mirosurile legate de capacitatea de livrare : Numărul de comentarii, timpul rămas, numărul de respingeri …

Indicatori de instrumente de gestionare

Instrumente de management, în plus față de servirea ca radiator de informații pentru a cunoaște situația curentă a produsului și ajută la coordonarea lucrărilor, ele sunt o sursă bună de informații despre indicatorii procesului de lucru.

Pentru a observa capacitatea întregii echipe într-un set de felii verticale este foarte utilă cunoaște timpul ciclului . La un timp de ciclu mai scurt, cu atât este mai mare capacitatea noastră de livrare. Este timpul necesar deoarece începe să lucreze la ceva care contribuie la valoarea (de exemplu, o poveste de utilizator) până când se întâmplă să se facă.

Este obișnuit că, la un moment dat, în instrumentele de gestionare puteți observa diferitele implementări care au fost făcute, unde putem obține frecvența implementării. Evident, mai frecvent, mai bine.

Deși timpul ciclului nostru a fost scurt și frecvența desfășurării ridicate, ar fi posibil ca produsul nostru să fie fragil datorită bug-urilor. Acesta este motivul pentru care indicatorul de erori detectate și rezolvate prin versiune / desfășurare este o altă metrică care este întotdeauna luată în considerare.

În funcție de momentul și scenariul în care se găsește un produs, cred, de asemenea, indicatorul lui Timpul de plumb, timpul trecut de când se întreabă ceva nou până când acesta este implementat în producție. Aceasta ar fi o consecință a celor trei indicatori anteriori și dimensiunea stack-ului de produs.

Așa cum cred că există cineva care poate pierde indicatorii despre estimări, iterația de tip povestiri de tip. În opinia mea, ele au o componentă foarte subiectivă și variabilă care trebuie utilizată ca indicator al schimbării capacității de livrare a unui computer.

Indicatori ai produsului în sine

în plus față de Un alt tip de instrumentație mai mare mai meticuloasă pe care membrii echipei de gestionare a produsului sau de proiectare au nevoie, echipa de dezvoltare ar trebui să poată observa numărul și procentul de utilizare a funcționalității, care în cele din urmă definește succesul sau nu a activității tuturor.

Cel mai interesant lucru despre acest indicator este că combinat cu alte valori pot ajuta la luarea deciziilor cu privire la evoluția produsului. De exemplu, acest scenariu:

  1. a detectat probleme de performanță foarte grave într-o parte a produsului.
  2. observăm că procentul de utilizare a funcționalității afectate de aceste probleme este Rezidual.
  3. Am decis să nu o rezolvăm în acest moment, dar o reflectăm în stack-ul de produs ca o prioritate mică.
  4. Configurează o alertă pentru a detecta o creștere a procentului de utilizare a acestei funcționalități.

Un alt indicator important este rata de accident a produsului, de câte ori este detectată o eroare sau o eroare în funcție de cantitatea de utilizare, ceea ce ne permite să știm cât de stabil produsul este. Și amestecate cu indicatorul numerelor de utilizare a funcționalității, ne permite să detectăm punctele problematice.

În funcție de contextul produsului și al afacerii, putem să luăm alți indicatori relevanți de operațiuni și sprijin care sunt o consecință a utilizării produsului.

Măsură fără a pierde focalizarea

acestea sunt multe kpis diferite. Este interesant de observat pentru că pot fi folosite pentru a detecta mirosurile despre probleme și oportunități de îmbunătățire, dar sunt prea mulți pentru a încerca să îmbunătățească totul la un moment dat.

pentru a evita diluarea și nu se termină deloc , ar trebui să alegem și să ne concentrăm în câțiva indicatori de fiecare dată, în funcție de situația fiecărei echipe.

și chiar dacă este tentant să faceți acest lucru, ar evita fericirea acestor indicatori pentru a marca obiectivele , precum și pentru a evalua echipamentul diferit.

Să nu uităm că scopul de a măsura acești indicatori este de a observa evoluția în momentul unei echipe care lucrează la un anumit produs și context.

Leave a Comment

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *