Să presupunem că mașina noastră de colecție are nevoie de un strat nou de vopsea. Sau trebuie să zugrăvim noua noastră casă. Vom angaja cei mai buni profesioniști, le vom cere să folosească cele mai bune materiale de pe piață si chiar vom accepta să plătim un preț mai mare decât media. Echipa angajată termină la timp, fără să depășească bugetul. Toată lumea e fericită și poate va fi și o mică petrecere de inaugurare! Dar, într-o lună sau două, mici pete de rugină sau crăpături apar în vopseaua proaspătă.. Ce s-a întâmplat? Cea mai bună echipă nu a lăsat suficient timp pentru stratul de suport să se usuce și au aplicat vopseaua după numai patru ore, nu șase, cât ar fi fost nevoie în conformitate cu specificațiile producătorului.
Ce lipsește din acest scenariu este un proces de execuție corect definit și urmărit in timp. Nu a fost vorba despre un pas sărit în intregime, ceva ce s-ar fi putut observa la timp pentru a fi corectat înainte de finalizarea lucrării, doar o mica scăpare ce nu părea semnificativă în acel moment dar care, în timp, s-a dovedit mai costisitoare decît întârzierea ce s-ar fi întâmplat dacă s-ar fi urmat specificațiile.
"Quality Assurance" reprezintă o suită de activități peste care se trece cu mult prea multă ușurință în echipele ce au adoptat modelul SCRUM. Motivele sau scuzele sunt multe, de la timpul scurt alocat dezvoltării și nevoii de a livra cât mai rapid un produs, la încrederea acordată echipei de testare până la neînțelegerea totală a conceptului de "calitate". Acest lucru nu este ceva ce poate fi trecut atât de ușor cu vederea sau amânat până când condițiile o vor permite - acel moment s-ar putea să nu vină niciodată. Consecințele pot fi semnnificative și pot merge de la timpul necesar fixării defectelor (pe cheltuiala proprie) până la pierderea încrederii clienților. "Asigurarea Calității" nu trebuie confundată nici cu "Controlul calității" - cea din urmă reprezintă ultima etapă în procesul de asigurare a calității, deoarece, pentru a fi siguri de rezultat, este nevoie de un produs funcțional, cât mai aproape de varianta finală.
Să începem cu definiția calității: calitatea unui produs (fie că e vorba despre un avion, un hot-dog, un serviciu sau un software) este un atribut distinctiv al produsului respectiv, în comparație cu un alt produs similar. Folosim expresia "produsul A este de calitate", dar aceasta are sens doar când comparăm acel produs cu un altul, similar. Mult mai des spunem "produsul X este de o calitate mai bună decât produsul Y", iar aceasta este în conformitate cu spiritul definiției de mai sus. Pâna la urmă calitatea înseamnă să livrăm ce așteaptă clientul să primească. Nu mai puțin (motivul e clar) dar nici prea mult, pentru că s-ar putea să nu fim plătiți pentru munca noastră.
Calitatea unui produs sau serviciu este o sumă a mai multor criterii de calitate, fie că sunt definite explicit la începutul proiectului, de către toate părțile implicate, fie sunt subînțelese, fără un acord scris. Asemenea criterii sunt (sau ar trebui) să fie rezultatul unei analize riguroase și a înțelegerii nevoilor utilizatorului final. Aceste nevoi sunt traduse în ceea ce numim "factori de calitate" (quality factors) ce vor fi mai apoi integrați în produsul final prin criteriile de calitate amintite mai sus. Aceste criterii trebuie să fie măsurabile și metricile astfel obținute vor fi folosite apoi atât pentru evaluarea calității produsului în timpul ciclului de dezvoltare și la momentul livrării cât și ca fundament pentru eventuale îmbunătățiri.
Calitatea unui produs este rezultatul unui mix a tot ce contribuie la dezvoltarea respectivului produs: factorul uman (echipa de proiect), echipamentul sau tehnologia pe care aceștia îl/o folosesc și procesul de lucru, prin care se transformă materia primă în produs final. Quality Assurance își propune să găsească acel echilibru perfect între cei trei actori ce contribuie la realizarea produsului.
Pâna la urmă calitatea este acel factor ce poate face diferența între produsul nostru și altele similare disponibile în piața liberă. Cel mai probabil există undeva în lume alte organizații cu același nivel de cunoștințe cu al nostru; unele dezvoltă produse similare cu al nostru, unele mai ieftin, altele mai repede. Nimic nu oprește un consumator în anul 2015 să aleagă celălalt produs. Doar calitatea produsului propriu poate să facă remarcat produsul care nu trebuie să fie perfect - nici nu există produse perfecte- dar trebuie să răspundă cât mai bine unei nevoi a consumatorului și să fie puțin mai bun decât al concurenței.
Peter Leeson -CMMI and Process Improvement Lead Appraiser and Instructor- a rezumat aceasta în articolul "Understanding Quality" de pe blogul personal:
Understanding quality is the most critical aspect of your job, whatever it is. Quality is what differentiates your products and services from the others. If your sole focus - as reflected by measurements is quick and cheap, you will lose the battle: there will always be someone cheaper than you.
http://www.qpit.net/blog/understanding-quality.html
Asigurarea Calității este un set de activități ce au ca scop includerea atributelor de calitate în produsul final. Este nevoie de implicarea activă a tuturor celor ce participă, indiferent de etapa din viața produsului, de nivelul de senioritate sau de locul în organigramă. Atât timp cât cineva poate influența dezvoltarea unui produs sau serviciu, are și o responsabilitate în asigurarea calității produsului rezultat.
Asigurarea calității se împarte în două categorii majore. În prima categorie intră activitățile de prevenire a defectelor în timpul procesului de dezvoltare prin definirea unui mod de lucru standardizat, stabilirea momentelor și frecvenței validărilor și verificarilor precum și revizuirea întregului proces. Măsurătorile a diferiți indicatori (KPIs), analiza acestor măsurători, măsurile de îmbunătățire sau de corectare a activității și evaluări periodice la toate nivelurile implicate sunt parte a acestui proces de prevenție. A doua categorie se concentrează pe detectarea defectelor în produsul final și este cunoscută și sub numele de Control al Calității.
Bineînțeles, toate cele de mai sus vin cu un cost asociat. În faza inițială a proiectului este nevoie de planificarea riguroasă a tuturor activităților legate de QA: identificarea nevoilor utilizatorului, translatarea acestora în obiective de calitate, planificarea monitorizării progresului, identificarea sau definirea celui mai bun model pentru întreg procesul de dezvoltare și lista poate continua. În timpul fazei de dezvoltare trebuie executate cu regularitate, conform planului, activități de monitorizare a performanței procesului de dezvoltare și a calității; este necesară planificarea momentelor de evaluare: frecvență, context și obiective; evaluarea progresului (sau a regresului) din perioada scursă de la ultima verificare; luarea măsurilor de corecție necesare dacă este cazul; evaluarea costurilor și a beneficiilor activităților executate (de exemplu: costul revizuirilor comparat cu costul necesar reparației unor eventuale defecte ce pot aparea în produsul final) și, în sfârșit, ajustarea întregului proces de muncă astfel încât să servească cât mai bine nevoilor proiectului.
Mai mult, rezultatele măsurătorilor colectate în timpul existenței proiectului de dezvoltare, împreună cu setul de practici cu utilitate dovedită în timp, constituie un bun valoros pentru orice organizație. Acestea pot fi folosite ca punct de plecare în dezvoltarea cu succes a unui nou produs sau în crearea unei noi echipe. Existența unui set de bune practici ce și-au dovedit în timp utilitatea pot fi de ajutor și în integrarea unor capacități suplimentare într-un sistem existent, fie că este vorba despre un nou membru în echipă, de un nou tool sau chiar un nou proces.
În concluzie, activitățile grupate sub denumirea generică de Quality Assurance sunt o componentă vitală în orice proces de dezvoltare a unui produs.Quality Assurance poate fi asemănată cu un echipament GPS folosit pe scara foarte largă în zilele noastre. Ajută la stabilirea unei rute și oferă o estimare a costului călătoriei. Totuși, acel aparat nu poate forța un șofer să urmeze ruta stabilită, dar, la nevoie, oferă rute alternative sau indicații către drumul ce a fost acceptat initial.
Fig. 1: Rolul QA intr-un proiect.
Prima afirmație din Manifestul Agile spune că acei care vor îmbrățișa această filozofie vor prețui mai mult "Indivizii și interacțiunea dintre aceștia în locul proceselor". Deci.. adăugarea unui proces nou într-un mediu Agile nu pare o idee foarte bună.
Citind mai departe manifestul Agile se spune limpede că, deși nu se contestă valoarea părții a doua din fiecare afirmație, se pune preț mai mare pe cea din partea stângă. Mai mult, în pagina dedicată istoriei mișcării Agile, scrisă de Jim Highsmith, găsim următorul paragraf (http://agilemanifesto.org/history.html):
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.
Putem verifica și printre cele douăsprezece principii Agile (http://agilemanifesto.org/principles.html): nimic nu interzice definirea unui proces care să ne ajute în munca noastră zilnică și astfel să ne folosim de ceea ce am învățat de-a lungul timpului. Nu cred că a spus cineva vreodată că prețuiește mai mult colaborarea într-o echipă în defavoarea calității. Sau, dacă a spus-o, e puțin probabil să mai conducă vreo afacere acum.
Oare este posibil ca un proces de management al calității să nu contravină principiilor Agile? Oare s-ar putea defini procese de lucru pentru diferite etape din viața unui proiect (sau produs), pentru fiecare rol implicat, în așa fel ca aceste procese să AJUTE o echipă Scrum?
Scrum -cea mai folsită "aroma" de Agile- este un model al unui proces de dezvoltare software. Se pune accent pe colaborarea între membrii echipei și între echipă și client în dorința de a răspunde mai repede nevoilor clientului, de a livra într-un timp mai scurt și de a reacționa mai bine la schimbare. Conform definiției, o echipă Scrum trebuie să fie capabilă să se organizeze independent și să aibă un nivel suficient de maturitate. Fiecare nevoie este acoperită, fiecare membru își cunoaște reponsabilitățile, știe exact ce are de făcut (și la nevoie execută fără nicio ezitare) și se adaptează foarte repede oricărei schimbări a mediului înconurător. Aceasta este mai mult definiția unui pluton al unei unități din forțele speciale, nu al unei echipe de programatori palizi. Din păcate, nivelul de maturitate necesar pentru funcționarea efectivă a unei echipe Scrum nu este ceva ce se poate obține peste noapte. Membrii echipei trebuie să înțeleagă la un nivel acceptabil clientul și nevoile de business ale acestuia astfel încât produsul dezvoltat să vină în întâmpinarea acestor nevoi. Fiecare membru al echipei trebuie să aibă încredere totală în omul de lângă el și este de așteptat ca ei să rateze de câteva ori înainte de a ajunge la cea mai bună soluție indiferent de problema asupra căreia își îndreaptă atenția într-un anume moment.
Așa cum am văzut mai sus fiecare membru al echipei joacă un rol important în construirea unui produs final de calitate. Din păcate, nu întotdeauna este clar acest lucru - responsabilitatea se diluează între toți participanții la procesul de producție și, câteodată, este ceva subînțeles ("suntem profesioniști, știm fiecare dintre noi ce avem de făcut"). Programatorii programează, tester-ii testează - pentru aceasta suntem aici pâna la urmă, nu? De ce un programator ar trebui să revizuiască scripturile sau cazurile de test? Nu este vorba despre o verificare din punct de vedere sintactic, dar să se asigure că munca proprie funcționează conform cu așteptările clientului și dincolo de cazul trivial (happy flow)! A contestat vreodată cineva rolul sau activitățile managerului de proiect într-o echipă Scrum? Doar există Scrum Master care să conducă echipa! Sau, pentru că există un Product Owner, de ce un rol de Requirement Engineer specializat? Această dezbatere ar putea continua la nesfârșit.
Quality Assurance poate ajuta o echipă Scrum să-și clarifice scopul și să păstreze ritmul și direcția astfel încât să-și atingă acel scop fără prea multe devieri pe parcurs. Ajută de asemenea la stabilirea unor responsabilități clare fiecărui rol implicat în procesul de dezvoltare. Prin definirea clară a unui mod de lucru, indiferent că vorbim despre dezvoltare propriu-zisă, despre felul în care sunt tratate defectele sau despre implementarea unor metode efective de monitorizare și control, se poate reduce riscul repetării acelorași greșeli pe parcursul dezvoltării produsului sau în cazul unuia nou. Când există un traseu clar, măsurabil, înspre scopul final se pot observa mai ușor eventualele deviații și permite să se intervină înainte ca acestea să se transforme în adevărate probleme pentru parcursul proiectului. Este un mecanism de siguranță ce poate preveni sau reduce semnificativ daunele ce pot să apară în unele cazuri. Un design sau un proces de dezvoltare perfect încă nu s-a inventat. Într-adevăr, câteodată costurile de implementare ale unui proces de calitate eficient pot fi și mai mari decât beneficiile (cum ar fi de exemplu un proiect mic, ce se poate realiza într-o perioadă scurtă iar corectarea eventualelor defecte poate fi suportată cu ușurință de către organizație). Într-un astfel de scenariu o firmă se poate baza pe experiența echipei, dar aceste cazuri sunt excepții și nu trebuie generalizate.
Prin observarea și revizuirea continuă a fiecărui aspect al produsului și a modului de lucru, întregul proces de dezvoltare prinde viață și evoluează în timp. Metodologia Scrum se concentrează asupra procesului de dezvoltare propriu-zisă a software-ului, dar aceasta nu e suficient pentru crearea unui produs de succes.
Dacă cineva ajunge să cunoască cele două lumi (Agile/Scrum și metodologia bazată pe procese) poate ajunge la un moment "evrika", în care își dă seama că acele două lumi nu se exclud reciproc! Poți defini un proces de lucru viu, care evoluează ca răspuns la schimbări, după modelul Agile. Sau, dacă se alege Scrum ca "armă" principală pentru dezvoltare, tot trebuie să implementăm un sistem de management al calității sau să ne asigurăm că cerințele produsului acoperă în întregime nevoile de business ale clientului. Acest fel de a privi lucrurile nu este nou și nici foarte dificil de implementat! Cea mai dificilă încercare este schimbarea modului de a gândi al membrilor echipei, să privească dincolo de task-ul curent sau de obiectivele pe termen scurt. Să faci o întreagă echipă să înțeleagă că scopul final nu este terminarea tuturor task-urilor la timp pentru demo ci construirea unui produs de care cineva își va aminti și peste doi-trei ani. În plus, toată experiența câștigată în timpul proiectului nu se va pierde și va putea fi folosită în viitor.
Iată ce spune Peter Leeson despre acest subiect:
Over the years, different terminologies have come into existence, which are considered as the new way of doing things. In theory, it means that people have identified the weaknesses of the way they are working and are therefore trying to find a new, more successful approach. In reality, it appears that the weaknesses due to misunderstanding and misapplication of basic principles have led to results which are very different from what was originally expected. We then get a group of people who believe that the new approach is the solution to all their previous problems and start following it with religious fervour, throwing out anything which does not correspond to the new vocabulary and focusing only on applying what they have understood from what they have read in a book - soon they are producing the same mistakes as previous generations and it becomes time for someone to re-create the basic ideas...
http://www.qpit.net/blog/getting-started-101-process-agile-or-lean.html
În concluzie, la fel ca în multe aspecte ale vieții de zi cu zi, adevărul este undeva la miloc. Nu există un adevăr absolut și niciun grup nu poate susține că are răspuns la orice întrebare. Nu există niciun "silver bullet" sau panaceu pentru orice încercare ce am putea-o întâlni.
ISDC a răspuns provocărilor de mai sus urmând calea de miloc. În urmă cu mai mult de cinci ani, cu suport total din partea echipei manageriale, un grup entuziast a început munca la ceea ce avea să devină un mod de metoda internă standard de implementare a calității și de dezvoltare continuă a tuturor activităților zilnice.
Fiecare proiect de succes a fost analizat și un set de bune practici a fost extras din experiența câștigată de-a lungul anilor. Aceste practici au fost grupate pe arii specifice ce acoperă fiecare aspect din "viața" unui proiect. Astăzi sunt 24 de procese definite ce includ aproximtiv 300 de task-uri descrise în detaliu (cine execută? Cum ar trebui executat? Când? Plus criterii de intrare/ieșire). Au fost definiți indicatori și măsurători specifice acestor indicatori. Acest grup funcționează și azi, analizând măsurători, răspunzând întrebărilor colegilor și implementând sugestiile de îmbunătățire ce vin din organizație.
Procesele astfel definite au devenit un standard intern și apoi a început munca de răspândire a experienței sintetizate în procesele definite înapoi în organizație.
Este imposibil să definești un proces ce să se potrivească oricărei situații, în orice proiect. Ca urmare s-a creat și un set de reguli pentru ajustarea proceselor definite astfel încât procesele să răspundă cât mai bine nevoilor proiectului. Acest set de reguli este de asemenea revizuit constant și este îmbunătățit continuu împreună cu definițiile proceselor.
A fost creată și o echipă specializată în quality assurance, condusă de Quality Manager, pentru a asigura suport echipelor de proiect în definirea unui plan de management al calității, în definirea obiectivelor de calitate ale produsului ce urmează a fi dezvoltat și de definire a unui mod de lucru standard pentru întreaga durată de viață a proiectului. QA Team observă modul de lucru într-un proiect și propune îmbunătățiri pe baza definițiilor de proces de la nivelul organizației sau promovează practicile ce pot aduce îmbunătățiri în munca altor echipe. QA Officers sunt un grup independent iar prin aceasta se asigură obiectivitatea evaluărilor modului de lucru al echipelor cu care colaborează. Pe lângă evaluări, QA Team identifică și documentează deviațiile, oferă feedback echipelor și conducerii pe tema caltății și a modului de lucru și se asigură că eventualele neconformități sunt adresate la timp. Pentru că lucrează aproape de echipele din proiecte QA Officers sunt în prima linie de promovare a standardelor interne și ajută la colectarea de feedback pentru dezvoltarea ulterioară a definițiilor de proces la nivel de organizație.
Standardul intern ISDC a fost construit pe baza modelului "Capability Maturity Model Integration for Development" (CMMI-DEV v1.3) creat de Software Engineering Institute, un centru de cercetare non-profit de la Carnegie Mellon University (www.sei.cmi.edu). Practicile interne ISDC au fost evaluate și certificate la nivelul 3 de maturitate conform standardelor SEI - ISDC fiind una dintre puținele organizații ce au obținut această recunoaștere în România.
Asigurarea calității este permanent în atenția tuturor de la ISDC deja de multă vreme. În afară de dezvoltarea continuă a proceselor și a tool-urilor folosite există o preocupare constantă în direcția îmbunătățirii factorului uman din ecuația calității: se organizează sesiuni "Continuous Improvement" destinate angajaților , iar QA Officers se întâlnesc mereu, formal sau informal, cu oricine are nevoie de un răspuns legat de asigurarea calității. Suntem vizitați cu regularitate de consultantul nostru extern și sesiunile organizate în aceste ocazii sunt deschise tuturor.
Chiar dacă principalul proces de dezvoltare al produselor noastre este Scrum există procese definite și pentru alte arii de proces. De exemplu: project planning; risk management; requirements development and management, release and configuration management, quality management și lista poate continua. Prin tot acest efort se încearcă reducerea probabilității apariției crăpaturilor în produsele noastre din cauza că vreun mic pas a fost trecut cu vederea la un moment dat și care se poate întoarce împotriva noastră într-un moment nepotrivit. Desigur, această posibilitate nu poate fi eliminată în întregime, dar depinde numai de noi să ne asigurăm că menținem aceasta la cel mai scăzut nivel posibil.
1. CMMI® for Development, version 1.3 - Improving processes for developing better products and services, November 2010,Technical report
3. http://www.qpit.net/blog.html - o serie de articole scrise de Peter Leeson, CMMI and Process Improvement Lead Appraiser and Instructor at Q:PIT Ltd.(http://www.qpit.net/contact-us.html)
4. "Quality Assurance - Making Process Work" - Peter Leeson la ISDC, Mai 2014
