Știm cu toții că modul în care se livrează produsele software s-a schimbat mult în ultimii ani. Este o nevoie crescândă de a livra din ce în ce mai repede și de a ne asigura că ceea ce livrăm este de cea mai bună calitate. Dacă până în urmă cu câțiva ani, echipele de dezvoltare aveau la dispoziție timp suficient pentru a proiecta o arhitectură, pentru a planifica foarte bine ceea ce au de dezvoltat, în ultimii ani aș putea spune că aceste echipe nu se mai pot bucura de prea mult timp. Tocmai din acest motiv, multe din noile metodologii de lucru au pus accent foarte mare pe timpul în care se face livrarea unui produs.
Trăim într-o lume globalizată, stare de fapt care începe să se vadă și în felul în care echipele sunt construite. Cu ceva timp în urmă echipele de dezvoltare erau situate în aceeași locație, același lucru nu mai este valabil și acuma. Aș putea spune chiar că majoritatea echipelor de dezvoltare software sunt acum distribuite pe fusuri orare diferite și în contexte culturale diverse. Cu toate acestea, exigențele privind calitatea produselor software a rămas la fel de mare.
Lucrând în acest mediu complex, echipele trebuie să livreze mai eficient, să răspundă rapid cerințelor ce vin de pe piață și mai ales, trebuie să livreze produse impecabile din punct de vedere al calității. De ce zic aceasta? Mai cu seamă acuma, un produs care nu răspunde nevoilor clienților, un produs care nu funcționează corespunzător și conține multe erori, va fi penalizat imediat de piața consumatoare. Motivul este foarte simplu: există pe piață foarte multe alternative. Concurența este foarte mare, indiferent de piața unde activați, fapt care adaugă presiune în plus pe echipe în a livra la cel mai înalt standard de calitate.
Aud în fiecare zi sintagme de genul "calitate ridicată", "calitatea produsului", "calitatea procesului", etc.. De-a lungul anilor, experiența mi-a arătat că fiecare dintre noi avem o percepție diferită asupra acestui termen calitate. Cu toate că ar fi mult mai simplu ca acest termen să fie ceva care să nu lase loc altor interpretări. Se pare că lucrurile sunt un pic mai complexe decât ne-ar face nouă plăcere să credem. Din punct de vedere al unui CEO, calitatea unui produs este dată de felul în care el monetizează acel produs. Dacă el vede că are un cashflow sănătos în businessul său, atunci el consideră că are un produs de calitate. Să luam un programator: dacă el observă că pentru codul scris de el sunt raportate foarte puține erori, el consideră că a scris un cod de calitate, nu-i așa? Mai departe, dacă un tester descoperă tot timpul multe erori în aplicația pe care o testează, atunci el consideră că munca lui este una de calitate. Cum stau lucrurile în cazul unui director de marketing? Dacă acesta observă că feedbackul primit din piață este unul pozitiv, în urma campaniilor construite și implementate de el, atunci cu siguranță va considera că a făcut o treabă de calitate. Exemplele pot continua, însă ce am vrut să reliefez aici este faptul că fiecare persoană are o percepție proprie asupra ceea ce înseamnă calitate. Până la urmă, putem avea o echipă în care fiecare membru să aibă rezultate de calitate, dar în ansamblu lucrurile să stea un pic diferit.
Consider că între valoare și calitate există o relație strânsă. De exemplu, în procesul de dezvoltare, orice începe cu o idee care pe baza unei analize mai amănunțite este detaliată și rafinată, după care este transpusă în niște specificații clare. Ulterior, aceste specificații ajung să fie implementate și testate. Bineînțeles că toate aceste etape sunt monitorizate. Cam așa s-ar înfățișa un proces de dezvoltare- dacă aplicăm o perspectivă foarte generală. În exemplul de mai sus, în fiecare etapă a acestui proces noi considerăm că ideea și implementarea ei au valoare. Cu alte cuvinte, avem o valoare asumată (assumed value).
Când un client primește această valoare, plecând de la ideea avută, doar atunci putem spune că aducem valoare prin ceea ce livram, doar atunci putem spune că ideea este valoroasă. Cu alte cuvinte, am plecat de la o valoare asumată și am ajuns la o valoare reală. Sună un pic complicat, dar dacă ne uitam cu atenție observăm că toate lucrurile se leagă. Ceea ce contează este să ajungem la o valoare reală. Singura care ne spune dacă am creat calitate. În imaginea de mai jos este reprezentat cum am evoluat de la o idee până la valoare.
Strâns legat de lucrurile pe care le-am detaliat mai sus, am citit în urmă cu ceva timp niște lucruri foarte interesante despre calitate, și mai ales de modul în care transformăm o valoare asumată într-o valoare reală. Modalitatea prin care se face această tranziție, a fost numită de unii "quality functions" - adică funcții de calitate. Pentru că pare interesant, voi expune mai în detaliu ce sunt aceste funcții de calitate.
Rezultatul final al unui proiect are o calitate ridicată atunci când aceste funcții de calitate au fost aplicate în fiecare etapă a proiectului, mai precis în fiecare dintre fazele acestuia: idee, cercetare, specificații, implementare și testare, instalare în producție, monitorizare. Putem spune acum că aceste funcții de calitate reprezintă un mecanism de a transforma valoarea asumată în valoare reală. Valoarea nu poate exista fără calitate, calitatea nu poate exista fără valoare, ele aflându-se de fapt într-o relație Ying-Yang.
Pentru că în lumea IT ne place să vorbim în limbaje de programare, aceste funcții de calitate pot fi definite de următoarea funcție:
Quality() {
researchAndRefine()
specify()
buildAndTest()
deploy()
monitor()
}Acest cod nu face altceva decât să sublinieze că de fapt calitatea nu este altceva decât aplicarea acestor funcții de calitate în fiecare fază a dezvoltării unui proiect.
Calitatea și produsele software fără erori (0-bug-software)
Produse software fără erori? Cum adică? Știm cu toții că erorile sunt prezente în produsele software, oricât de bine ar fi scris codul și oricât de perfecționiști am fi. La un moment dat, aceste erori își vor face apariția, fie după o utilizare intensivă a produsului, fie prin descoperirea unor cazuri de funcționalitate izolate (așa numitele corner-cases). Care ar fi cea mai bună soluție de gestionare a acestor erori? V-ați întrebat vreodată dacă se poate face ceva în plus astfel încât aceste situații frustrante să fie izolate sau chiar să dispară de tot?
O abordare foarte interesantă este "0-bug-software", care nu este altceva decât o abordare a felului în care gestionăm erorile. Menționez încă de la început că acest mod de lucru necesită foarte multă disciplină la toate nivelele, începând de la developeri, testeri, business owneri și până la managerii de produs. De fapt, în opinia mea, consider că aceasta este cea mai mare provocare a acestui mod de lucru: de a reuși să impunem o disciplină pe toate palierele de lucru.
Începem prin a invita product ownerii să clasifice toate taskurile existente într-una din următoarele categorii:
Probleme critice,
Erori,
Funcționalități,
Următorul pas este acela în care echipa de dezvoltare va trebui să pună pe prim plan rezolvarea acestor taskuri. Pentru a descrie nivelele de prioritate voi face o analogie cu un magazin fizic, ce vinde anumite produse consumatorilor:
Probleme critice. Sunt acele probleme care fac magazinul să fie nefuncțional. A luat foc magazinul, noi avem un incendiu major - deci dacă nu stingem focul, nu mai avem magazin. Destul de clar, nu? Prioritatea acordată rezolvării unor astfel de probleme este foarte ridicată: clienții nu mai primesc deloc valoare din produs, cu alte cuvinte banii sunt aruncați pe fereastră. Ca mesaj pentru echipa de dezvoltare: te oprești din orice ai face și rezolvi problema.
Erori. Mi s-a părut sugestivă analogia următoare: erorile sunt ca o scurgere de apă ce o ai la magazinul tău. Dacă lași prea mult această apă să se scurgă, s-ar putea să te trezești cu o inundație și să te vezi pus în situația să închizi magazinul. Așadar, erorile nu le oferă clienților produsele de care ar trebui să beneficieze (vorbesc aici strict din punct de vedere al funcționalităților). Ce trebuie să facă echipa de dezvoltare? Pur și simplu să rezolve aceste erori după ce termină la ce lucrează în acel moment.
Funcționalități. Funcționalitățile sunt ca și produsele comercializate în magazin. Magazinul nu poate exista fără produse, iar produsele nu pot exista fără un magazin unde să fie vândute. E vorba aici de un melanj ce asigură succesul. Anumite taskuri sunt funcționalități atunci când ele nu există deja în actualul produs. Când trebuie să se lucreze la aceste funcționalități? Ele sunt abordate în ordinea priorității din backlog.
Îmbunătățiri. Aici vorbim de acele lucruri care aduc ceva în plus magazinului tău. Sunt acele lucruri care fac vitrina să atragă clienții sau îi fac pe clienți să revină în magazinul tău. Gândiți-vă la lucrurile ce diferențiază magazinul de altele de pe stradă. Aceste taskuri sunt cele care îmbunătățesc o funcționalitate deja existentă. La fel ca orice altă funcționalitate, trebuie să se lucreze la ele în ordinea priorității din backlog.
Aceasta este pe scurt abordarea "0-bug-software". Cum precizam și la începutul secțiunii, e foarte important de înțeles că disciplina în acest mod de lucru trebuie să fie fără cusur. Nu se admit excepții, nu se admit devieri de la acest comportament. La prima vedere pare un sistem foarte rigid, dar nu este deloc așa. Astfel se asigură un mod de lucru ordonat de abordare a oricărui task și orice trebuie implementat în produsul software.
De obicei suntem obișnuiți cu anumite clasificări ale erorilor. Echipele de dezvoltare lucrează la anumite erori în ordinea priorităților. Adică, sunt erori critice, erori majore și erori minore. În abordarea "0-bug-software" un task sau e eroare sau nu. Nu există nuanțe de gri în acest tablou. Ori este negru ori alb. Cu alte cuvinte dacă la întrebarea "Poți trăi fără un anumit task?" răspunsul este "da", atunci în mod evident nu este vorba despre o eroare ci despre o îmbunătățire adusă sistemului. Clasificarea erorilor este binară.
Bineînțeles, nu putem să lăsăm erorile toate în aceeași oală. Trebuie cumva triate și diferențiate pentru că, nu-i așa, nu toate sunt la fel. De aceea, în acest mod de lucru intervine și o clasificare a erorilor, care este cam așa:
Erori de implementare,
Specificații incorecte,
Vă rog să citiți atent exact cum sunt clasificate erorile. Nu-i așa că puteți la orice oră să încadrați orice eroare cu care v-ați întâlnit, în una din aceste categorii? Bineînțeles, vor apărea discuții referitor la această clasificare. Este totuși important ca în cadrul echipei să fim onești și să admitem de fiecare dată când o eroare face parte dintr-un grup enumerat mai sus și pur și simplu să fie încadrată acolo. E important să reținem că orice eroare poate fi clasificată:
ca problema critică, sau
ca funcționalitate nouă, sau
Mi-a plăcut următoarea definiție: "By enforcing a strict set of classification and handling rules, you get prioritization discipline for free."
Vă oferim câteva exemple despre cum se pot clasifica unele erori într-una din categoriile de mai sus.
Eroarea apărută este una cu care se poate trăi? Adică, eroarea respectivă ne asigură o funcționalitate corectă în ansamblul aplicației? De exemplu: Imaginile ar trebui downloadate și cache-uite în alt tread.
În acest caz, eroarea semnalată va fi re-clasificată ca fiind Îmbunătățire.
Lipsa specificațiilor va implica o nouă funcționalitate? De exemplu: În pagina în care se afișează utilizatorii, nu se pot edita in line anumite câmpuri. În acest caz re-clasificăm această eroare ca Funcționalitate Nouă.
Descrierea incompletă a unei funcționalități are un impact major asupra businessului. De exemplu: Pe o pagină se va contoriza de câte ori s-a dat click pe un produs, când de fapt noi vrem să contorizam de câte ori s-a comandat acel produs. E doar un exemplu ipotetic al unui magazin online. În acest caz, re-clasificăm această eroare ca fiind Problemă Critică.
Cum am spus mai sus, acest sistem necesită o disciplină din partea tuturor celor implicați în proces, de la echipa de management, business analysts până la echipa de dezvoltare și testare. Cred că efortul cel mai mare este în momentul în care se începe modul de lucru dezvoltat mai sus. Ideea este că trebuie de la început să se treacă prin toate taskurile și absolut toate trebuie clasificate cum am detaliat mai sus. Fără excepție! Ok, veți spune, dar avem în backlog sute sau poate mii de taskuri. Aș spune că e un moment bun să faceți curățenie. Sunt convins că multe din acele taskuri sunt foarte vechi sau unele chiar nu mai sunt deloc de actualitate și nu se mai reproduc. Bineînțeles că echipa de dezvoltare nu trebuie să aștepte până nu sunt puse la punct toate taskurile. După ce au fost parcurse să spunem 10-20% din imensa listă, și taskurile au fost re-clasificate, echipa de dezvoltare își poate face treaba. Dar e important ca toate taskurile să fie clasificate așa cum am detaliat mai sus. Este un efort destul de mare la început, dar apoi lucrurile vor funcționa foarte ușor.
Consider că marele dezavantaj al acestui sistem, este acela că toți actorii trebuie să fie implicați, chiar și oamenii care fac parte din management sau cei orientați spre partea de business - și aici ne vom lovi poate de o disponibilitate limitată a lor, din punct de vedere al timpului. Nu-i nimic, avem soluții și în acest caz. Eu recomand să se stabilească niște ședințe săptămânale, în care să fie implicați acești oameni și care să ajute la această re-clasificare. De obicei, aceste ședințe trebuie să fie foarte rapide. În aceste ședințe se va trece prin lista de taskuri și se vor clasifica folosind sistemul de mai sus. Făcând treaba aceasta de mai multe ori, după câteva ședințe lucrurile se vor așeza iar imensa listă de taskuri va scădea cu siguranța. În produsele mari, acolo unde și echipele de dezvoltare sunt mari, eu recomand să se meargă pe modelul "three amigos" (îl voi detalia pe scurt în cele ce urmează). Acest sistem aduce la aceeași masă oameni care au responsabilități diferite în cadrul procesului și îi va ajuta în primul rând să dezvolte o mai ușoară comunicare între ei și nu numai.
Deci, se cuvine în acest moment să specificăm foarte clar ordinea în care tratăm aceste taskuri. Primele vin situațiile critice, apoi cele ce sunt în lucru, erorile și apoi în cele din urmă vin taskurile din backlog adică îmbunătățirile și funcționalitățile noi.
Board într-o reprezentare de tip Kanban
Acest concept nu este nou. El a fost pentru prima dată menționat în anii '60 de către Philip Crosby, un legendar expert în calitate din Statele Unite. Ca și multe alte concepte, și acesta a fost aplicat la început în industria aviatică și ulterior în anii '90, în industria auto. La început, Crosby a numit aceasta metodologie Zero-Defect.
Aș dori acum să aruncăm o privire asupra unui concept interesant, care este implementat în unele companii:"Three Amigos". Este important de remarcat și legătura dintre acesta și "0-Bug-Software". Pe aceste două concepte le văd mergând mână în mână și cred că este interesant cum am putea să livrăm mai eficient și mai repede.
Se cuvine să clarificăm ce este acest concept, cum a apărut și care ar fi principalele lui caracteristici. Știm cu toții că în cele mai multe companii se adoptă Scrum sau Kanban. Când vorbim de companii, de cele mai multe ori vorbim de departamente întregi care se aliniază până la urmă să funcționeze după niște ritualuri bine stabilite ca și Scrum-ul.
Până la urmă de unde a plecat acest concept de "Three Amigos"? Ținând cont că în tot procesul de Scrum sunt implicați diferiți actori, fiecare pleacă la drum cu un bagaj de cunoștințe, adică un nivel de înțelegere a lucrurilor și fiecare înțelege lucrurile pe limba sa. Mai exact, product ownerii vorbesc în termeni ca UAT și user stories, business analyst-ii discută folosind termeni cum ar fi specificații sau criterii de acceptanță, developerii folosesc termeni drept cod sau unit teste sau oamenii responsabili de calitatea produsului care folosesc termeni ca scenarii sau test cases. Observați că fiecare din acești actori au un "limbaj" propriu și un nivel propriu de înțelegere a lucrurilor cu toate că ei lucrează în aceeași echipă.
În tot acest peisaj apare la un moment dat confuzia, complexitatea și duplicitatea. Mai exact, confuzia apare acolo când echipa trebuie să stabilească de ce e nevoie ca o funcționalitate să fie completă. Complexitatea este foarte importantă, manifestându-se atunci când unul din actorii implicați face o modificare în tot acest proces fără a estima ce impact are asupra celorlalți actori. Bineînțeles, duplicitatea poate să apară în momentul în care unii dintre acești actori ajung să facă din nou ceva ce a mai fost implementat. De exemplu, unit testele scrise acoperă integral funcționalitatea sau e nevoie și de teste manuale?
Așadar, avem niște actori implicați în acest proces, care prin prisma faptului că au un nivel de cunoștințe și un limbaj total diferit pot genera anumite nivele de confuzie, complexitate sau duplicitate.
Ce face de fapt "Three Amigos"? Acest concept reprezintă de fapt încă o ședință, care se adaugă la Scrum și care ar trebui să rezolve toate problemele enumerate mai sus. Încă o ședință? Poate vi se pare absurd deoarece și așa echipele care adoptă Scrum au un nivel de rezistență destul de mare la a mai adopta încă o ședință. Să știți că nu este. Această ședință se desfășoară oricum, doar că de cele mai multe ori oamenii din echipele de dezvoltare (și mă refer aici strict la developeri și testeri) nu sunt implicați. Aceasta este o ședință în care se discută anumite specificații, se detaliază și se analizează funcționalitatea ce trebuie implementată. De obicei, această ședință se desfășoară înainte ca un task să ajungă în backlog. Se presupune că un task va ajunge în Backlog doar după ce a fost validat.
Cum se validează un task? Foarte simplu. În această ședință vor participa câte un reprezentant din echipele de business analyst, developeri și testeri. Deci, această ședință va avea 1 BA, 1 developer și 1 QA.
Sunt multe avantaje de a avea pe toți trei actorii în acest meeting. Nu uitați că în această fază pur și simplu se detaliază anumite specificații, se răspunde la întrebări, se lămuresc lucrurile. E foarte important pentru că se clarifică specificațiile, se discută în această echipă și dacă toată lumea este pe aceeași lungime de undă din punct de vedere al dezvoltării, al testării și al businessului. Limbajul comun încet își face loc și lumea va începe să înțeleagă foarte bine și bucăți din această imagine, ce nu sunt disponibile pentru ei. Echipa de dezvoltare va înțelege și de ce se implementează o anumită funcționalitate, cum va fi ea testată de fapt, iar BA-ul va avea ocazia să vadă exact cum gândesc oamenii implicați direct în dezvoltare.
Eu aș recomanda ca orice funcționalitate nouă sau orice îmbunătățire a unei funcționalități existente să treacă prin acest filtru, al celor 3 Amigos. Acest lucru asigură o consistență în modul de abordare a tuturor taskurilor. Este de fapt o garanție că o funcționalitate este pregătită să intre în procesul de dezvoltare, cu specificații complete, întrebări care au răspunsuri clare,aspect ce face ca estimările ce vor veni să fie foarte exacte.
Se cuvine să trecem în revistă care sunt beneficiile unei astfel de abordări, Three Amigos:
Crește interacțiunea în echipă datorită modului de lucru, prin prisma faptului că vom avea cei 3 amigos în permanentă interacțiune.
Nivelul de înțelegere al businessului crește. Echipa de dezvoltare fiind direct expusă și pe partea de business, adică echipa va înțelege de ce se implementează o anumită funcționalitate. De cele mai multe ori, bazat și pe experiența mea, lipsa acestei interacțiuni a dus la un nivel de frustrare legat de ce se implementează.
Vor apărea grupuri de experți pe anumite zone de funcționalitate - lucru ce face ca de fiecare dată când există o problemă, oricine din acest grup să poată să răspundă la întrebări sau să depășească anumite impedimente.
Se conștientizează de către fiecare ce implicații are munca lor asupra celorlalți.
Specificațiile vor fi din ce în ce mai bune, mai exacte și pe un limbaj comun, înțeles de toată lumea.
Se poate merge până în punctul în care se poate introduce un nou status în workflow-ul folosit de echipă, astfel încât, un task nu poate ajunge în sprint dacă nu a trecut prin filtrul Three Amigos.
Se pot optimiza de asemenea și anumite sesiuni de planificare, astfel încât ele să se desfășoare concomitent în mai multe grupuri. (Bineînțeles, dacă este posibil.)
Ținând cont că lucrurile evoluează constant și destul de rapid, aș vrea să fac o recomandare. Eu aș adăuga în acest grup de 3 actori pe încă unul. Bine, grupul va deveni Four Amigos. Dar am motive întemeiate. Și anume, ținând cont că aplicațiile din ziua de azi încep să conțină interfețe destul de complexe, aș adăuga pe cineva de pe UI/UX sau un frontend developer. Marele avantaj este că atunci când avem în acest grup o persoană orientată pe partea de user experience sau pe partea de frontend development este că putem surprinde încă din această fază anumite probleme de interfață, anumite limitări sau anumite probleme ce vor duce la o creștere a timpului de implementare. De obicei, am ajuns să văd partea de UI că ia foarte mult din timpul de implementare, devine foarte complexă, generează foarte multe probleme. Și atunci, pentru a limita aceste probleme, recomandarea mea este să mergeți pe Four Amigos. Cu siguranță veți începe să vedeți și voi beneficiile.
Nu în ultimul rând, aș merge mai departe și aș aplica ce am discutat la începutul acestui articol despre "0-bug-software". Mai exact, putem implementa această metodologie la nivel de grup, și anume, la nivelul "Three Amigos" sau "Four Amigos". Adică, tot ce am discutat despre erori, funcționalități, îmbunătățiri, dar la nivel de story/epic.
Ideea este să identificam cum putem funcționa mai eficient și mai bine în fiecare echipă. Ține foarte mult de experiența oamenilor din echipă, cât de deschiși sunt acești oameni la schimbări și mai ales cât de mult putem jongla cu aceste metodologii. E important să încercăm lucruri noi, să analizăm dacă funcționează sau nu și apoi să ne adaptăm. Nu vrea nimeni să aibă niște procese ca la carte, dar care să nu asigure un nivel de eficiență dorit atât de client cât și de echipă.
Apoi, e important tot timpul să reușim să scalăm orice proces am folosi. Produsele evoluează, procesele evoluează, lucrurile se mișcă alert iar noi suntem datori tot timpul să încercam să scalăm procesele de fiecare dată când ajungem în puncte critice, indiferent care sunt ele. Într-un articol viitor voi împărtăși cu voi modul cum putem scala unele procese. Până atunci, mult succes în orice faceți și nu uitați să aveți curaj să încercați lucruri noi, lucruri care pot duce la o mai bună eficientizare a proceselor.
"Învață din greșelile altora. Nu poți trăi destul pentru a le face pe toate." - Anna Eleanor Roosevelt
Mi-au servit ca inspiratie urmatoarele articole:
Robotics & AI
de Mihai Varga
de Călin Diniș , Mihai Tentis
