experiența noastră în utilizarea celor mai comune metrici Agile

experiența noastră în utilizarea celor mai comune metrici Agile

utilizarea metricilor Agile pentru a măsura productivitatea echipei este partea cheie a filozofiei Agile. Managerii de echipă și toți membrii ar trebui să vadă consecințele muncii lor și să utilizeze aceste date pentru a îmbunătăți fluxul de lucru și a crește eficiența.

utilizatorii finali și clienții pot beneficia, de asemenea, de utilizarea valorilor Agile project care se concentrează pe evaluarea rezultatului produsului. Valorile permit Scrum masters, dezvoltatorilor, proiectanților și testerilor să măsoare performanța aplicației și să urmărească dacă sarcinile curente și anterioare îmbunătățesc produsul.

în acest articol, vom examina valorile Agile care contează și vom împărtăși experiența noastră de a aplica acest tablou de bord pentru valori Agile la un proiect din viața reală. Se pare că, pentru a conduce o echipă cu succes și pentru a obține rezultate, nu trebuie doar să știți ce valori să aplicați, ci cum să o faceți — vom împărtăși cum ne-am dat seama.

tipuri de valori Agile comune

clasificarea valorilor Agile nu este pusă în piatră — este mereu în schimbare și restructurare. Totuși, de-a lungul anilor, am văzut creșterea a trei tipuri principale de valori Agile în diferite cadre Agile.

1. metrici Kanban — aceste valori se bazează pe măsurarea timpului investit (timpii ciclului) și a rezultatelor livrate (debitul) și a raportului acestora.
2. Scrum metrics-metrici, care sunt axate pe planificarea și înțelegerea fluxului de lucru și demonstrarea cât de multă muncă a fost efectuată într — o anumită perioadă;
3. Lean metrics-măsurarea continuă a eficienței producției și a calității produsului cu evaluare tehnică prin testarea caracteristicilor, verificarea posibilelor erori și anticiparea efectelor negative.

folosim toate cele trei tipuri de valori pentru a evalua principalele aspecte ale procesului de dezvoltare software și rezultatele: calitatea produsului, productivitatea echipei și sănătatea.

metrici de calitate Agile

înainte de a începe să măsurați viteza și eficiența echipei, trebuie să știți dacă vă deplasați în general în direcția corectă. Care este utilizarea în livrarea promptă a tuturor sarcinilor de dezvoltare, dacă sarcinile în sine sunt formate în mod greșit? Prioritatea pentru fiecare echipă de dezvoltare software și manager este să se asigure că toate activitățile sunt legate de îmbunătățirea produsului — acest lucru se face prin măsurarea calității acestuia și detectarea tendințelor negative.

defecte scăpate

fiecare proiect agil are sprinturi sau cicluri de lucru, la sfârșitul cărora este livrată o anumită sarcină. După finalizarea lucrărilor, managerul echipei trebuie să evalueze calitatea rezultatelor obținute. Toate modificările, modificările și erorile nefixate sunt defecte scăpate — probleme pe care dezvoltatorii le-ar fi putut remedia, dar nu au făcut-o. înregistrați numărul și natura lor exactă pentru a ști ce greșeli scapă de obicei ochilor dezvoltatorilor.

după ce ați făcut un raport privind defectele evadate și ați colectat statistici tangibile, trebuie să discutați rezultatele cu echipa dvs. Asigurați-vă că fiecare membru al echipei știe ce fel de erori îi lipsește de obicei echipei. Dacă aveți sugestii individuale, discutați-le cu membrii echipei unu-la-unu.

implementări eșuate

dacă produsul a fost implementat, dar nu a fost lansat sau nu a reușit să atragă utilizatori, acest lucru este înregistrat ca o implementare eșuată. Uneori, o implementare eșuată se întâmplă cu deciziile uneia dintre părțile interesate sau modelul de afaceri se dovedește a fi nesigur. Oricare ar fi fost cauza problemei, trebuie să înregistrați toate implementările eșuate împreună cu motivele eșecului lor.

înainte de a lansa o nouă implementare, echipa poate arunca întotdeauna o privire la lista implementărilor eșuate anterior și poate examina dacă aceasta nu poate suferi același proces. Analiza motivelor eșecului versiunilor anterioare permite evitarea problemelor viitoare.

Release Net promotor Score (NPS)

scorul Net Promotor este metrica care implică evaluarea reacțiilor utilizatorilor în Feedback cantitativ (numere, statistici, evaluări medii) și calitativ (recenzii, feedback direct, mesaje, e-mailuri, apeluri). După ce echipa a colectat și analizat feedback-ul, fiecare membru al echipei sugerează un scor care evaluează cât de mult este probabil ca utilizatorul să recomande produsul (de obicei, scorurile sunt stabilite în limite de la 1 la 10).

metrici de management de proiect Agile

după ce aveți un istoric complet al eșecurilor și succeselor anterioare, puteți analiza direcția luată pentru toate proiectele incomplete actuale și puteți oferi sarcini relevante, bazându-vă pe experiențele anterioare. După ce ați stabilit direcția de dezvoltare — „ce trebuie să faceți” a produsului, „trebuie să evaluați eficiența echipei-este factorul” cum facem”. Puteți utiliza valorile Agile project pentru a ști dacă membrii echipei îndeplinesc așteptările dvs., înțeleg sarcinile lor, gestionează termenele limită și dacă toate procesele sunt coordonate și sincronizate.

Lead time

Lead time este o metrică care permite echipelor să verifice cât a fost nevoie pentru ca intrarea din jurnalul de produse să ajungă la sfârșitul sprintului. Poate fi folosit pentru a urmări produsele în orice etapă de dezvoltare, sarcină după sarcină sau pentru a evalua cheltuielile totale de timp, de la idee la eliberare. Este o metrică pe termen lung pe care dezvoltatorii o pot utiliza în timp ce își planifică activitatea viitoare și estimează prețurile.

asigurați-vă că pentru a înregistra timp de plumb pentru fiecare dintre proiectele tale. Cel mai bine este să păstrați atât statistici cu imagini mai mari care acoperă întregul proiect, cât și să organizați valori sprint-astfel încât să puteți examina fiecare etapă separat.

durata ciclului

dacă timpul de plumb se numără printre valorile de performanță pe termen lung ale echipei, timpul ciclului se concentrează pe sarcini individuale. Această metrică evaluează durata unui singur ciclu, unde un ciclu este luat de o singură sarcină, calculează numărul de cicluri pe proiect și măsoară rezultatele realizate pentru utilizatorul final dacă produsul este deja testat beta sau lansat.

cu timpul ciclului, echipele pot vedea imediat dacă o sarcină durează prea mult sau dacă unii membri ai echipei nu își îndeplinesc obiectivele. Această valoare pe termen scurt face managementul de proiect mult mai ușor și ajută la identificarea rapidă a problemelor pe măsură ce apar.

Sprint burndown

această valoare se aplică atât pe termen scurt, cât și pe termen lung. Managerii pot crea rapoarte sprint burndown Scrum în timp real pentru a urmări progresul echipei lor în proiectul curent — pentru aceasta, trebuie să estimeze numărul total de sprinturi și să prezică cheltuielile probabile de timp. De asemenea, poate fi utilizat pe termen lung-managerii pot analiza rapoartele privind proiectele anterioare, pot identifica etapele care nu au reușit termenele așteptate și pot analiza cauzele întârzierilor.

cel mai important, Sprint burndown permite urmărirea dinamicii fluxului de lucru al echipelor. Unii membri tind să lucreze mai lent în primele etape, în timp ce alții ard spre sfârșitul proiectului. Cu Sprint burndowns, liderii de echipă pot detecta aceste tendințe, pot determina cauzele lor și pot ajuta membrii cu distribuția muncii și gestionarea timpului.

Epic& Release burndown

această valoare este similară cu Sprint Burndown — singura diferență cheie este că se concentrează pe productivitatea echipei înainte și după lansare. Managerii pot adăuga noi cerințe și pot încorpora sarcini care se bazează pe feedback-ul utilizatorilor finali. Este o versiune îmbunătățită a sprint burndown, deoarece încorporează și sarcini date după lansarea proiectului.

Velocity

această valoare evaluează numărul de puncte de poveste finalizate într-o anumită perioadă. Pe baza istoricului dvs., puteți prevedea cheltuieli de timp pentru viitoarele puncte de poveste. Scăderea vitezei echipei pe anumite sprinturi poate indica o neînțelegere între membrii echipei sau sarcini indicate care sunt mai grele decât se anticipase anterior.

valorile Agile suplimentare

ajută echipa să-și cunoască mai bine proiectul și să țină evidența multor aspecte semnificative ale dezvoltării produsului. Există, de asemenea, valori Agile pentru directorii superiori care permit vizualizarea imaginii mai mari a dezvoltării și a bunăstării echipei. Conform experienței noastre, aceste valori suplimentare vă ajută să măsurați orice aspect al muncii dvs. Cu toate acestea, am definit caracteristicile cheie care spun cel mai mult despre produsul final și ajută la obținerea unui rezultat complet complet.

Flux cumulativ

numele metricii își comunică clar scopul — de a acumula toate fluxurile proiectului și de a le evalua într-o singură diagramă. Având un astfel de grafic vă va oferi o vizualizare la scară largă-poate fi trimisă părților interesate din proiect care nu au timp să analizeze rapoarte Agile mai detaliate.

diagrama descrie de obicei următoarele procese:

• sarcini în backlog: câte sarcini în backlog membrii echipei au în intervalul de timp dat;
• lucrări aprobate: câte SARCINI dintre cele planificate au fost finalizate — managerul echipei vede imediat diferențele dintre activitățile planificate și cele finalizate;
• SARCINI tampon: toate lucrările care așteaptă aprobarea sunt definite ca fiind într-o zonă tampon;
• în curs: trebuie să evaluați volumul de lucru curent.

cod putinei

această valoare arată tendințele de cod de bază modificări înainte de lansare. Diagramele putinei arată cât de mult cod a fost adăugat, eliminat sau modificat o dată la un moment dat. La sprinturile timpurii, vor exista multe vârfuri și căderi pe grafic, deoarece codul este încă instabil, dar pe măsură ce proiectul progresează, graficul codului putinei ar trebui să devină stabil, fără urcușuri și coborâșuri drastice.

înainte de lansare, putina ar trebui să obțină un declin — adăugarea sau editarea codului înainte de lansare înseamnă că nu va fi supus unor teste suficiente. În general, ori de câte ori există o neregulă pe graficele Agile, investigați motivele.

diagrama de Control

o diagramă de control este o diagramă în care echipa poate vedea informații despre durata timpilor ciclului lor. Rezultatul ideal ar avea linia de pe diagramă în mod constant merge în jos cu timpul — aceasta ar însemna creșterea vitezei echipei — mai puțin timp este necesar pe un singur ciclu. Un alt aspect important este coerența-timpii ciclului trebuie să rămână chiar indiferent de tipul sarcinii — înseamnă că aveți o distribuție corectă a muncii.

metrici de sănătate

echipele de dezvoltare Software trebuie să se concentreze pe priorități pe termen lung, cum ar fi menținerea comunicării între membri și verificarea dacă toată lumea este mulțumită. Agile este o metodologie flexibilă, ceea ce înseamnă că se poate adapta intereselor diferiților membri, de îndată ce managerii știu la ce să acorde atenție. Iată cum aflăm dacă toți membrii echipei noastre sunt mulțumiți de fluxul de lucru.

fericire

dacă aveți relații informale de încredere în echipa dvs., este mai ușor să începeți cu un dialog deschis cu fiecare membru. Cereți tuturor să-și evalueze experiența în companie de la 1 la 5. Puteți pune întrebări de asistență — care sunt cele mai bune și cele mai rele aspecte ale muncii lor, ce ar putea fi îmbunătățit și ce ar putea crește fericirea? Dacă echipa nu are obiceiuri de comunicare prietenoase, utilizarea sondajelor anonime poate duce la rezultate mai obiective.

moralul echipei

moralul echipei și fericirea nu sunt aceleași lucruri. Fericirea are mai mult de-a face cu confortul, în timp ce moralul echipei este legat de productivitate, stima de sine, evaluarea propriilor calități profesionale. Din nou, puteți cere angajaților să-și evalueze moralul de la 1 la 5 și să pună următoarele întrebări;

• lucrul în companie v-a ajutat să vă îmbunătățiți abilitățile?
• cât de mult este explorat întregul dvs. potențial cu volumul de muncă actual?
• îți place munca ta?
• Vezi rezultatele clare ale muncii tale?
• ești entuziasmat de proiecte noi?

scopul aici este de a înțelege că curentul de dezvoltare al echipei merge în direcția cea bună. Uneori, managerul echipei de dezvoltare software ia sarcini profitabile, dar plictisitoare, ignorând interesele membrilor. Acest sondaj vă va ajuta să vedeți dacă angajații sunt încântați și provocați de munca lor.

cifra de afaceri a membrilor echipei

dacă managerii de echipă înlocuiesc frecvent membrii echipei, înseamnă că mediul de lucru este probabil nesănătos. O anumită rată a cifrei de afaceri în timp este sănătoasă — de fapt, nu doriți să adăugați oameni de ani de zile, deoarece ar însemna stagnare. Cu toate acestea, ar trebui să aveți grijă la vârfurile bruște ale activității — luni în care mai mulți oameni au părăsit echipa sau s-au alăturat mulți oameni. Dacă aveți o adăugare bruscă a multor participanți noi, trebuie să acordați atenție procesului de îmbarcare înainte de a merge direct la lucrările legate de proiect.

măsurarea beneficiilor pentru utilizatorii finali

echipele Agile ar trebui să știe cât de bine se potrivește produsul nevoilor unui utilizator final și ale proprietarului afacerii. Acest lucru se face cu o analiză cuprinzătoare a codului care determină calitatea codului și gradul de utilizare a acestuia pentru un utilizator final, precum și posibilele complicații de întreținere.

analiza statică a codului

este tipul simplu de analiză a codului atunci când software-ul este inactiv. Doar prin monitorizarea automată a Codului cu instrumente open-source, puteți identifica problemele de securitate, detecta datoriile tehnice și erorile și puteți trimite fragmente de cod problematice colectorului de gunoi.

analiza dinamică a codului

analiza dinamică a codului necesită ca echipa dvs. să ruleze software pentru a evalua experiența primită de utilizatorii finali. Încurajăm dezvoltatorii și testerii noștri să se pună mereu în locul utilizatorilor, explorând cele mai frecvente scenarii. De exemplu, își pot prezenta colegii și membrii familiei la soluție, solicitând feedback — cu excepția cazului în care nu este interzis de acord. Cel mai important, avem o echipă de profesioniști QA care sunt pe deplin responsabili pentru analiza dinamică a codului — deși credem că cu cât mai mulți oameni contribuie la testarea valorilor în Agile, cu atât este mai bună calitatea produsului final.

cum să aplicați cele mai bune valori Agile

dintre toate varietățile de valori Agile disponibile, trebuie să le selectați pe cele care vor fi relevante pentru echipa și proiectele dvs. pe termen lung. Urmărirea acestor caracteristici cheie ar trebui să fie un obicei, în timp ce nu ar trebui să vă distragă atenția de la o muncă mai urgentă. Iată cum am încorporat fără probleme valorile Agile în fluxul nostru de lucru.

concentrați-vă pe performanță, buget și calitate

trebuie să vă asigurați că, după selectarea tuturor valorilor, veți putea avea o imagine clară a calității, încărcării, cheltuielilor de timp și bugetului muncii dvs. În primul rând, am stabilit valori pe termen scurt care se referă la proiectele noastre active: timpul ciclului și viteza pentru evaluarea performanței Agile, analiza codului pentru evaluarea calității codului și fluxul cumulativ pentru a ține evidența tuturor proceselor de dezvoltare și a costurilor acestora.

în timpul primului sprint, ne asigurăm că facem următoarele:

• definiți câte sprinturi și cicluri va avea proiectul;
• estimați cheltuielile de timp pentru întregul proiect, ținând cont de nevoile clientului;
• evaluarea soluțiilor competitive pentru a înțelege nivelul de complexitate al produsului final;
• colectați feedback de la membrii echipei noastre cu privire la așteptările lor cu privire la aspectele cele mai interesante, provocatoare și dificile ale proiectului.

în acest fel, putem ști cât timp vom petrece pentru a finaliza proiectul, putem stabili standarde de calitate bazate pe soluții similare și dacă echipa noastră este motivată să lucreze la sarcini sau nu (are un impact imens asupra productivității).

metrici după primul sprint

aici, ne concentrăm pe obținerea de feedback de la client și de la toți membrii echipei. După primul sprint, vrem să știm că toate părțile implicate în fluxul de lucru înțeleg procesul și se simt confortabil. De asemenea, punem accentul pe evaluarea calității codului — planificăm chiar analiza codului și evaluarea datoriilor tehnologice ca parte a fiecăruia dintre sprinturile noastre următoare. De îndată ce au fost scrise primele linii de cod, menținerea calității sale este prioritatea noastră.

viteza vine după

viteza este una dintre cele mai importante valori din proiectele noastre, dar nu cea cheie. Ne abținem să ne bazăm judecata pe numerele de viteză în etapele inițiale. Strategia de a trece rapid prin primii pași este un dezastru care așteaptă să se întâmple — echipa ar putea sări peste planificare sau ar putea uita să pună unui client câteva întrebări cruciale. Nu grăbim primele etape ale produsului, lăsând clienții și membrii echipei să-și găsească ritmul.

creșterea vitezei echipei noastre devine una dintre prioritățile noastre atunci când suntem la punctul de execuție. De îndată ce toate caracteristicile și designul sunt stabilite, ne străduim să minimizăm cheltuielile de timp și să finalizăm toate sarcinile cât mai repede posibil.

valori individuale

fiecare dintre valorile utilizate ar trebui să fie disponibilă pentru întreaga echipă și pentru membrii individuali. Dezvoltatorii, testerii, designerii ar trebui să poată vedea ritmul și rezultatele muncii lor, nu doar o echipă în ansamblu. Pentru a face acest lucru, folosim instrumente de productivitate și trackere de timp, cum ar fi Jira și Hubstaff. Toate rapoartele generale sunt sincronizate cu cele individuale-Membrii pot vedea ce procent din timpul total productiv fac orele lor.

Întrebări frecvente

ce este KPI în Agile?

indicatorii cheie de performanță în Agile sunt valori măsurabile care arată eficiența echipei în atingerea obiectivelor de afaceri. Indicatorii KPI la nivel înalt se concentrează pe rezultate pe termen lung care depind de mulți factori — câți utilizatori au fost atrași de produsul final, ratele de conversie, calitatea feedback-ului. KPI-urile de nivel scăzut sunt valori pe termen scurt care nu sunt influențate de mulți factori Conectați-timpul petrecut în proiect (de obicei calculat în ore), bugetul proiectului (investiție pe sarcină) etc.

Agile este o metodologie de dezvoltare bazată pe îmbunătățirea continuă — dezvoltarea de software analizează datele și se adaptează la acestea. Echipa analizează KPI-urile Agile cu privire la performanța și calitatea muncii sale și implementează schimbări imediat, în următorul sprint.

ce sunt valorile Sprint?

valorile Sprint sunt valori care evaluează livrabilele echipei de dezvoltare software, verificând câtă valoare a fost livrată clientului final până la sfârșitul fiecărui sprint . Această valoare poate fi măsurată cu o caracteristică nouă, îmbunătățiri de proiectare sau ștergerea erorilor.

următorul obiectiv al Sprint metrics este de a măsura eficacitatea echipei în termeni de afaceri — cât de repede a fost livrată soluția pe piață, care este feedback-ul clientului și nivelurile de conversie. În cele din urmă, valorile trebuie să arate satisfacția dezvoltatorilor cu proiectul lor și cu direcția pe care echipa o ia în general.

de ce sunt valorile importante pentru proiectele Agile?

întregul punct al metodologiei Agile este că dezvoltatorii pot face întotdeauna corecții în proces după fiecare sprint. Având date tangibile, statistici și grafice permite dezvoltatorilor să înțeleagă ce schimbări să facă pentru următorul sprint și permite evaluarea calității produsului final — altfel, ar fi ușor să fii prins în detalii tehnice și de organizare.

ce este un sprint în Agile?

un sprint este o perioadă clar definită, cu data de început și de sfârșit, când echipa este stabilită pentru a finaliza un anumit număr de sarcini. Sprinturile stau la baza Scrum, Agile și DevOps — echipele își împart volumul de muncă în bucăți mai mici gestionabile și urmăresc rezultatele fiecărui sprint. Fiecare dintre aceste perioade este tratată ca un mini-proiect cu o planificare prealabilă, evaluarea riscurilor, misiuni de responsabilitate și analiză post-sprint.

fiecare proiect este compus dintr-o serie de sprinturi. Deoarece fiecare sprint este evaluat, este ușor să identificați problemele din timp și să le eliminați la următorul sprint — astfel încât fluxul de lucru este optimizat constant.

care sunt valorile pentru dezvoltarea de software?

metricile de dezvoltare Software sunt valori cantitative care permit măsurarea calității, performanței și sănătății echipei proiectului de dezvoltare software. Ele ajută la îmbunătățirea procesului de dezvoltare pe măsură ce proiectul se mișcă și pot fi utilizate pentru activitatea viitoare a echipei pentru a îmbunătăți organizarea și planificarea.

există șase tipuri principale de metrici de dezvoltare software:

• metrici formale de cod — acestea sunt valori calitative obiective care calculează cât de multă muncă a fost efectuată prin determinarea numărului de linii de cod (LOC), lungimea căii de instrucțiuni și altele.
• Metrici de eficiență pentru dezvoltatori — echipa poate calcula codul de atribuire, zilele active și timpul petrecut în sarcină.
• metrici de proces Agile — când proiectul este împărțit în sprinturi, echipa poate măsura eficiența părților mai mici ale Proiectului – Timpul de plumb (cât timp a fost petrecut pentru o anumită etapă de dezvoltare, care poate conține mai multe sprinturi), timpul ciclului (un sprint se încadrează de obicei într-un singur ciclu) și viteza (câte sarcini au fost efectuate într-un anumit interval de timp).
• metrici operaționale-aceste valori verifică caracteristicile de funcționare ale software-ului și determină cât de eficient este personalul companiei în menținerea instrumentului fără ajutor de la terți. Mean Time Between Failures and Mean Time to Recover (MTTR) verificați modul în care software-ul va rula în circumstanțe naturale și cât de echipată este echipa internă în gestionarea sarcinii.
• valori de testare-aceste valori evaluează acoperirea codului — cât de mult a fost testat codul, Numărul de erori și procentul datoriei tehnologice.
• satisfacția clienților-echipa primește informații despre reacțiile utilizatorilor finali la produs prin măsurarea scorului net al promotorului, a Scorului de satisfacție a clienților și a scorului efortului clienților. Aceste valori evaluează, respectiv, dacă utilizatorii ar recomanda produsul și dacă sunt mulțumiți de rezultat.

valorile Agile fac parte din rețelele software și pot cuprinde și alte categorii, după cum puteți observa din ghidul nostru.

ce sunt valorile SDLC?

SDLC este un ciclu de viață al dezvoltării de software — Un set de etape pe care o tehnologie tipică le suferă în timpul concepției, execuției și finalizării sale. Un SDLC mediu constă în următoarele etape:

• evaluarea sistemelor existente și definirea caracteristicilor, avantajelor, problemelor acestora;
• definirea cerințelor pentru noua funcționalitate a proiectului, design, publicul țintă etc.;
• proiectarea sistemului și conturarea unei căi tipice de utilizator;
• dezvoltarea software-ului, ceea ce înseamnă scrierea codului, pregătirea hardware-ului și crearea de caracteristici;
• testarea performanței software-ului, funcționalitate, securitate, interfață, etc.;
• implementarea software-ului în mediul său natural, unde tehnologia va funcționa pe termen lung;
• menținerea sistemului prin actualizarea codului, înlocuirea sau editarea anumitor fragmente și eliminarea erorilor.

fiecare etapă a SLDC poate fi măsurată prin următoarele caracteristici.

• cerințe: echipa trebuie să colecteze toate cerințele pentru proiect și să evalueze implementarea fiecăruia în termeni de timp și bani;
• calitatea Software-ului: toate valorile de calitate Agile pot fi utilizate în etapa de dezvoltare a unui SDLC;
• cazuri de testare: echipa trebuie să calculeze numărul de activități de testare efectuate, viteza și acoperirea finală a codului;
• defecte: pentru a măsura eficiența muncii lor, dezvoltatorii și testerii trebuie să fie conștienți de numărul exact de probleme care apar în timpul dezvoltării;
• SARCINI: măsurarea timpului petrecut iar banii câștigați pe sarcină permit evaluarea dacă toți membrii echipei sunt productivi sau nu.

toate valorile descrise în ghidul nostru pot fi utilizate în diferite etape ale ciclului de viață al dezvoltării Software-ului. Proiectul are cea mai mare nevoie de monitorizare mai aproape de lansare, deoarece problemele se pot acumula și este ușor să pierdeți un defect critic al produsului.

ce este tranzitată în metrici Agile?

este metrica care calculează numărul de povești finalizate pe sprint. În Scrum, o metrică similară este denumită viteza Sprintului.

concluzie

valorile Agile au creat o bază solidă pentru luarea deciziilor în cunoștință de cauză pe parcursul unui proiect de dezvoltare software. Dezvoltatorii pot folosi aceste informații pentru a-și crește eficiența în următoarele sprinturi și pentru a îmbunătăți constant calitatea produsului lor. Cu toate acestea, merită remarcat faptul că valorile de dezvoltare nu ar trebui să devină o prioritate absolută în proiectul de dezvoltare software. Dezvoltatorii ar trebui să se bazeze, în primul rând, pe nevoile proiectului și preferințele publicului.

la Jelvix, folosim o abordare personalizată pentru aplicarea valorilor proiectului. În primul rând, discutăm MVP-ul proiectului cu clientul, cercetăm publicul țintă, analizăm soluțiile competitive și abia apoi alegem valorile care se potrivesc cel mai bine proiectului. Nu ne străduim să aplicăm fiecare KPI — în schimb, le selectăm pe cele care reflectă cel mai mult nevoile proiectului.