Într-un articol mai vechi publicat aici, în TSM, am încercat să clarific ce este "Quality Assurance" și cum se potrivește într-un proiect agile. În prezentul articol, voi continua cu descrierea primilor pași ce trebuie făcuți în definirea și implementarea unui proces de management al calității într-un proiect de dezvoltare software.
La fel ca în orice activitate managerială, managementul calității ar trebui să înceapă cu stabilirea unui obiectiv și cu un plan în care să se detalieze:
Toate activitățile ce se vor executa în vederea atingerii obiectivului stabilit;
Resursele necesare pentru îndeplinirea activităților;
Frecvența și durata de timp alocat acestor activități;
Programarea sesiunilor retrospective - pentru evaluarea și revizuirea rezultatelor obținute în urma aplicării planului.
De asemenea, se recomandă includerea în plan a criteriilor de succes și a ROI (return of investment) adus de aceste activități.
Pe scurt, calitatea unui produs sau serviciu este ceea ce diferențiază produsul nostru în comparație cu produsele similare ale competitorilor, acel ceva ce face ca rezultatul muncii noastre să fie remarcat în contextul actual al pieței produselor software. Calitatea ar trebui să fie obiectivul final al tuturor activităților noastre - orice altceva este doar o unealtă, o metodă, un mijloc prin care să ne atingem acest scop sau obiectiv.
Calitatea este o sumă a mai multor obiective (sau criterii) de calitate ce trebuie stabilite clar încă din primele etape ale ciclului de viață al unui proiect. Criteriile de calitate trebuie definite și acceptate de toți cei implicați în proiect. Un rol important în acest demers îi revine în mod obligatoriu echipei cu întregul suport managerial al acesteia. Dar este recomandabil ca și doleanțele clientului să fie luate în considerare. Bineînțeles, obiectivele de calitate trebuie să fie definite și formulate inteligent (specific, measurable, achievable, relevant și time-bound) pentru a fi într-adevăr utile și ușor de monitorizat.
Obiectivele de calitate ajută echipa de proiect în eficientizarea modului de lucru, dar și în evaluarea rezultatelor muncii înainte de finalizare, prevenind ca eventuale defecte sau neconcordanțe să fie livrate clientului.
Obiectivele de calitate nu trebuie confundate cu specificațiile nefuncționale (NFR - non-functional requirements), cunoscute și sub numele de atribute ale calității (quality attributes). Acestea din urmă se presupune că se referă explicit sau nu la o nevoie a utilizatorului, cum ar fi uptime sau numărul de conexiuni concurente ce ar trebui suportate de o aplicație web. Aceste NFR fac obiectul arhitecturii sau managementului infrastructurii proiectului.
Câteva exemple de obiective de calitate ar fi:
"Reducerea numărului de defecte cu 25% în următorul trimestru față de trimestrul anterior" - presupunând că numărul de defecte raportate în cursul trimestrului anterior este cunoscut;
"Procentajul timpului alocat pentru re-work să fie menținut sub 25% din timpul total petrecut în development în fiecare sprint";
Un exemplu de obiectiv de calitate greșit este "reducerea numărului de defecte cu 25% în fiecare sprint". Nu este ceva ce poate fi atins (matematic) și nici delimitat clar în timp, spre deosebire de primul exemplu din lista de mai sus.
Ce activități ar trebui executate pentru atingerea scopului definit prin obiectivele de calitate? Acestea pot fi grupate în trei categorii: acțiuni de prevenție, activități de evaluare și activități de reparare/corect
Acțiunile preventive includ activități educative, astfel încât membrii echipei de proiect să își poată îndeplini mai bine sarcinile, pentru a eficientiza folosirea cunoștințelor proprii sau ale utilitarelor ce le stau la dispoziție. Activitățile de cercetare-dezvoltare (R&D) care conectează membrii echipei la noutățile din domeniu, planificările și activitățile de monitorizare și măsurare se înscriu și ele în această categorie a acțiunilor preventive. Acțiunile corective pot să fie astfel declanșate din timp, înainte ca eventualele inconsistențe sau inadecvări din produs sau metode de lucru să devină adevărate probleme.
Evaluările trebuie în primul rând să fie obiective și să fie făcute ținînd cont de un set de standarde, așteptări sau model. Activitățile de evaluare includ revizuirile, testele și auditurile.
Orice rezultat al muncii unei echipe poate fi evaluat: cerințele formalizate ale clientului (requirements), produsul în sine, orice plan sau documentație create de-a lungul perioadei de viață a proiectului, precum și activitățile zilnice executate de către echipă - al căror rezultat este produsul final. Pe lângă requirements, arhitectura sau configurația produsului software poate constitui subiectul unei evaluări care să-i asigure pe membrii echipei că rezultatul muncii lor este corect și complet iar pe clienți, că nevoile de business îi sunt luate în considerare și implementate. Chiar și felul în care o echipă își desfășoară activitățile de zi cu zi poate fi ameliorat în urma unei evaluări făcute corect și la timp.
Activitățile de testare și revizuire sunt binecunoscute - nu trebuie detaliate aici. Auditurile, în schimb, necesită câteva clarificări: trebuie executate de către un auditor independent și calificat, din afara echipei de proiect (de ex. un coleg arhitect, senior, atunci când este vorba de arhitectura software a proiectului sau un consultant extern dacă se dorește evaluarea produsului din perspectiva unui standard cum ar fi ISO). Auditurile trebuie planificate din timp, scopul și obiectivele trebuie cunoscute și asupra lor trebuie convenit cât mai devreme de la începerea proiectului. Obiectivele pot fi definite în interiorul proiectului sau organizației (chiar dacă după un model extern, cum este modelul CMMI) sau pornind de la un set de standarde la nivelul industriei software. Constatările auditului trebuie incluse într-un raport iar acestea trebuie aduse la cunoștința tuturor celor interesați.
Constatările (fie neconcordanțe, fie bune practici, fie sugestii de îmbunătățire) vor fi transformate în action points cu un responsabil și cu termen clar de execuție. Acestea vor face obiectul unei sesiuni extraordinare de re-evaluare, ca parte a sesiunii curente de audit.
Acțiunile de fixare/reparare constau în tot efortul necesar pentru depanarea sau corectarea defectelor descoperite în produsul muncii echipei, fie înainte, fie după livrare. În domeniul nostru de activitate acestea sunt cunoscute ca bug fixing, dar NU trebuie limitate doar la asta. Procesul de dezvoltare al produsului poate fi ajustat la nevoie, structura echipei se poate schimba dacă este necesar, iar lista rămâne deschisă. Bineînțeles, orice schimbare trebuie precedată de o analiză riguroasă - nu ne-am dori să descoperim că, implementând o schimbare, costul asociat va depăși bugetul alocat sau, mai rău, să constatăm că rezultatul nu este conform așteptărilor ori necesar.
Sunt trei "actori" ce contribuie și influențează dinamica unei echipe de proiect: membrii echipei (disponibilitatea acestora, cunoștințele și calificările lor), tehnologia (ce sprijină și dă posibilitatea membrilor echipei să-și ducă munca la bun sfârșit într-un mod eficient) și procesele de lucru (felul în care membrii echipei își folosesc zilnic cunoștințele și tehnologia avută la îndemână). În orice moment, pe durata de viață a proiectului toate aceste trei "ingrediente" trebuie să fie în echilibru. Bineînțeles, fiecare dintre resursele amintite aici vin cu un cost asociat ce trebuie avut de asemenea în vedere - cel puțin din perspectiva rentabilității proiectului.
Din punctul de vedere al asigurării calității, costul asociat acesteia (CoQ) se poate rezuma în următoarea formulă:
CoQ = CoP + CoN + CoA
Unde:
CoP este costul activităților preventive: upgrade-urile hardware sau software, costurile instructajelor sau ale cursurilor necesare, activitățile de planificare și analiză etc. .
CoN reprezintă costul reparațiilor: efortul necesar pentru fixarea defectelor, retestarea fixurilor, costul livrării modificărilor, rescrierea unor componente sau (în cazuri extreme) a întregului produs. Este probabilă și nevoia pentru asigurarea de suport constant, 24/7, clientului atunci când este necesar nevoilor sale de business, iar lista rămâne, din nou, deschisă.
Scopul unui plan de management al calității corect, cu șanse reale de reușită, va fi menținerea costului total al calității (CoQ) la un procent acceptabil în cadrul costului total al proiectului prin echilibrarea constantă a costurilor asociate activităților de prevenire și evaluare astfel încât costul activităților de fixare să fie cât mai mic.
Costul asociat activităților de asigurare a calității pot fi suportate intern, în cadrul organizației, sau pot fi partajate cu clientul - presupunând că, în timpul negocierilor, departamentul de vânzări are toate datele necesare pentru a-l convinge că este în interesul său. Existența unor exemple de succes a activităților de QA este un atu în plus în mâna departamentului de vânzări, colegii noștri putând dovedi unor potențiali clienți că, investind timp sau bani în activități de evaluare, pot obține un produs la un cost total mai mic, prin reducerea numărului de defecte și, implicit, a costurilor necesare fixării acestora.
Unele dintre activitățile descrise mai sus se întâmplă o singură dată, altele trebuie efectuate periodic sau constant pe întreaga durată de viață a proiectului.
Activitățile singulare sunt cele de felul negocierilor ce preced semnarea unui contract sau planificarea și estimările inițiale, high-level. Din perspectiva asigurării calității, stabilirea obiectivelor de calitate, definirea procedurii de măsurare și monitorizare, frecvența cu care se colectează măsurătorile, identificarea competențelor tehnice necesare îndeplinirii sarcinilor de proiect și evaluarea din acest punct de vedere a persoanelor disponibile, crearea planurilor manageriale sunt exemple de astfel de activități singulare. Din momentul în care acest tip de activități sunt încheiate iar rezultatul lor (planificări, documente) sunt aprobate de către cei responsabili, este puțin probabil ca acestea să se mai modifice pe întreaga durată de viață a proiectului. Dar aceasta nu înseamnă că nu trebuie să facă subiectul unei revizuiri periodice! Periodicitatea procesului de revizuire și factorii ce pot declanșa aceasta trebuie descrise: un contract se poate revizui sau înnoi anual ori în caz de forță majoră. Arhitectura unui produs software sau etapele (milestones) dezvoltării acestuia pot de asemenea suferi modificări, care vor declanșa la rândul lor revizuiri sau chiar modificări ale tuturor planurilor manageriale, asigurându-se astfel alinierea cu nevoile de business și obiectivele clientului și ale organizației din care facem parte.
Revizuirea, verificarea, validarea și monitorizarea tuturor aspectelor ce compun un produs trebuie efectuate continuu, fie că este vorba de requirements, cod scris, manuale de utilizare sau procesele de producție. Fie că se întâmpla zilnic, săptămânal sau per sprint, acestea trebuie să fie întotdeauna în vederea întregii echipe de proiect.
Sesiunile de audit trebuie de asemenea planificate. Planificarea nu trebuie să conțină datele sau durata exactă a acestora, dar frecvența (anual, semestrial sau o dată la fiecare release major), setul de reguli sau standarde aplicate, precum și procedura de audit (intern, extern, bazat pe interviuri sau pe observație independentă) trebuie descrise în planificarea activităților de asigurare a calității.
Din momentul în care obiectivele de calitate sunt definite și schița planului de asigurare a calității este disponibilă, membrii echipei de proiect împreună cu conducerea organizației (sau orice alte persoane interesate în bunul mers al proiectului) se angajează să urmeze acest plan. Obiectivele de calitate devin scopuri în sine pentru membrii echipei și este în responsabilitatea managerului de proiect, ori a altei persoane desemnate special pentru asta, ca aceste obiective să fie atinse în intervalul de timp și bugetul alocat.
Pentru monitorizarea corectă a activităților legate de asigurarea calității și a fi siguri că echipa urmează calea planificată trebuie definit un set de măsurători specifice fiecărui obiectiv, împreună cu frecvența de colectare și analiză a acestor măsurători. Lista de tool-uri disponibile pentru monitorizarea, măsurarea și raportarea activităților din cadrul unui proiect este suficient de mare, începând cu Jira sau TFS pentru managementul timpului sau altor aspecte ce țin de activitățile zilnice într-un proiect (bugs, work items, user stories) și mergând până la tradiționalul Excel pentru consolidarea rezultatelor și prezentarea acestora într-o formă grafică atrăgătoare.
Tipurile de issues sau stories precum și etapele dezvoltării (sau reparației) acestora, tranzițiile de la idee la produsul final, pot fi personalizate în Jira - de exemplu- astfel încât să reflecte cât mai bine obiectivele de calitate asupra cărora s-a convenit. Astfel se pot identifica, număra sau filtra foarte ușor activitățile legate de quality assurance precum și eventualele costuri asociate. Înregistrarea estimării inițiale pentru fiecare work item trebuie încurajată iar progresul în cazul fiecărui asemenea work item trebuie monitorizat constant de-a lungul întregii durate de viață a proiectului.
Fig. 1 - Un exemplu de workflow extins în Jira
În acest fel deviațiile, tendințele, pot fi identificate și folosite mai apoi pentru îmbunătățirea predictibilității tuturor activităților din proiect. Înregistrarea oricăror neconformități trebuie făcută folosind un issue type corect, ceea ce va permite mai târziu, în cadrul procesului de analiză, identificarea corectă a sursei și a momentului raportării. Se stabilește dacă problema a fost descoperită în faza de review, la testare sau, în cel mai rău caz, raportarea vine de la client?.
Numărul neconformităților sau al problemelor legate de calitate precum și timpul petrecut pentru analiza și rezolvarea lor poate fi astfel monitorizat separat de activitățile "normale" din cadrul proiectului, iar aceasta poate furniza multe informații despre calitatea produsului sau a activităților din proiect în general. Aceste informații pot fi prezentate într-o formă grafică sugestivă, astfel încât să se poată observa clar tendințele pentru perioada următoare. Mai departe, pe baza acestor direcții observate, bunele practici din rutina zilnică pot fi folosite ca o bază în definirea unor noi obiective de calitate sau promovate și în alte echipe de proiect. În mod similar, practicile al căror rezultat este sub așteptări sau sunt cauza creșterii numărului de issues, pot fi atacate din timp și stopate înainte să devină incontrolabile.
O dată ce o acțiune, chiar document, din cele descrise mai sus își dovedește utilitatea pe baza măsurătorilor, poate fi refolosită în alt proiect sau chiar să devină standard intern al organizației. Măsurătorile colectate de-a lungul timpului pot constitui de asemenea argumente puternice în favoarea oricărei practici în momentul în care s-ar dori prezentarea acestora ca un studiu de caz unui potențial client. Și reciproca afirmației de mai sus este adevărată: măsurătorile colectate pot convinge mult mai ușor orice echipă sau persoană să renunțe la o rutină al cărei rezultat nu este conform așteptărilor.
Fig. 2 – Reprezentare grafică a măsurătorilor colectate
Reprezintă momentul de reflecție, de evaluare a activităților legate de asigurarea calității executate până la acel moment. Sesiunile retrospective trebuie planificate la intervale regulate sau după atingerea unui milestone. A întârzia această sesiune până la finalizarea produsului nu este recomandată deoarece puține lucruri mai pot fi îmbunătățite în acest moment. Lecțiile învățate în perioada scursă de la ultima sesiune retrospectivă trebuie notate și folosite la îmbunătățirea managementului asigurării calității pentru următoarea perioadă, în toate aspectele sale: planificare, resurse, obiectivele de calitate, definirea și colectarea măsurătorilor sau activitățile ce vor fi executate.
Calitatea oricărui produs sau activitate este de o importanță capitală în lumea de azi. Scopul final al unui proiect de dezvoltare software trebuie să fie realizarea unui produs de calitate, nu doar implementarea de noi funcționalități. Un nivel înalt de calitate - fie că este vorba de produsul final sau de felul în care o echipă își desfășoară activitățile zilnice - trebuie să rămână o preocupare constantă a fiecărui membru al echipei. Pentru atingerea acestui obiectiv, echipa trebuie să-și identifice obiectivele de calitate și, de asemenea, să își planifice toate activitățile legate de acest scop. Beneficiile investițiilor în asigurarea calității, făcute complet și corect, sunt infinite în termeni de satisfacție a clientului și a echipei, prin diminuarea numărului de defecte posibile (și deci a efortului necesar reparării acestora) în produsul final, livrat clientului. De asemenea, investiția într-un plan stabilit încă de la începutul oricăror activități poate asigura economii importante mai târziu