Andreea Zdrobau 
Floris Cosmin Pop Agilitatea nu mai este doar un substantiv comun, ci a devenit un framework, un cadru de lucru și chiar un mod de a fi, în contextul dezvoltării proiectelor de anvergură. Aceasta este o realitate întâlnită în aproape toate domeniile, de aceea nu mai surprinde pe nimeni că este prezentă și în cazul proiectelor informatice.
Însă apare întrebarea: pentru a profita de noile tehnologii web, rescrierea unei aplicații scrisă inițial într-o tehnologie care a devenit implacabil obsoletă nu se poate face decât într-un framework Agil? În fond, aplicația există deja, funcționează bine și, în principiu, nu există "necunoscute" sau "surprize" care să prefigureze riscuri de dezvoltare a unor funcționalități nepotrivite sau chiar inutile.
Mai mult, obiectivul principal este rescrierea cât mai rapidă a aplicației, intervenind cât mai puțin posibil asupra perimetrului funcțional. Acest obiectiv este dublat de evoluția aplicației, în vederea îmbunătățirii sale și va avea loc într-o etapă consecutivă rescrierii.
Dar dacă perimetrul funcțional nu evoluează, unde mai e "agilitatea"? Ei bine, noi am descoperit-o, însă nu acolo unde ne așteptam.
Desigur, ca în orice proiect cu durată estimată la peste un an de zile, acesta are o mulțime de componente complicate care se amplifică reciproc. În acest caz, specificațiile aplicației curente sunt literalmente inexistente, doar utilizatorii "știu" ce face aplicația; "de ce"-ul, în termeni de nevoi de business, este cunoscut de câțiva privilegiați ale căror experiențe sunt centralizate de un stakeholder: Product Owner (PO). Noi, în calitate de analiști de business (BA) în cadrul echipei de dezvoltare avem, cum era de așteptat, rolul de proxy. Echipa de dezvoltare este o una dedicată, off-shore, iar specialiștii tehnici (technical leads) fac parte din mai multe echipe care vorbesc (nativ) mai multe limbi.
Am abordat proiectul cu optimism știind că echipa de proiect, deși diversă și răspândită în mai multe țări, dorește să colaboreze pentru scopul comun, iar stakeholderii care dețin informațiile cruciale sunt dispuși și disponibili să acorde sprijinul. Iar acest fapt, din fericire, s-a confirmat la fiecare pas.
Vorbind de pași, prezentăm în continuare, cât se poate de succint, etapele procesului de analiză, elaborat și folosit intens pe parcursul proiectului.
În prezent, procesul numără mai multe etape, începând de la analiza funcționalităților existente, continuând cu extragerea detaliilor suplimentare din codul sursă, organizarea sesiunilor de UI redesign și încheindu-se cu crearea de User Stories și prezentarea lor în cadrul Refinementului.
Primul pas este reprezentat de decizia luată de către PO în privința funcționalității ce urmează a fi analizată. Această decizie are în vedere factori precum dependența față de componentele ce au fost migrate până la momentul respectiv sau componența echipei în următoarele sprinturi.
Având în vedere implicarea în proiect a doi BA, se vor avea în vedere și cunoștințele dobândite de fiecare dintre aceștia, pentru o alocare cât mai eficientă a efortului de analiză.
Urmează analiza funcționalității de către BA. Dacă inițial această etapă consta în testarea paginilor din aplicație și colaborarea cu PO în crearea paginilor de specificații în Confluence, complexitatea ridicată a unor pagini și regulile ascunse pot conduce la nevoia folosirii unei abordări de tip "Reverse engineering" pentru extragerea specificațiilor. Astfel, am apelat la fișierele sursă pentru o înțelegere mai aprofundată a regulilor și a condițiilor specifice fiecărei pagini. Datorită acestui pas suplimentar, am diminuat considerabil și riscul de a omite interdependențe între paginile analizate la momente depărtate de timp.
În anumite instanțe, este necesară și crearea use case-urilor (cazuri de utilizare). Această etapă a apărut după ce am acoperit majoritatea funcționalităților simple (intuitive) și am ajuns la funcționalitățile complexe. Acest pas implică reguli de business stufoase și non-intuitive, care pot genera cazuri de eroare greu de materializat în aplicație și care trebuie totuși verificate și validate atât în etapa de dezvoltare, cât și în etapa de control al calității (QA internal test).
Ulterior, PO este responsabil de revizuirea specificațiilor. În această stadiu, este important ca utilizatorii atestați să fie notificați cu privire la potențialele schimbări provocate de adaptarea flowului la noul framework.
Un alt pas în analiza paginilor complexe este sesiunea de redesign, în cadrul căreia participă Business Analyst-ul, Product Owner-ul si Team Lead-ul (TL). Acum se urmărește adaptarea funcționalităților existente la noul framework. Doar în mod excepțional se introduc îmbunătățiri care pot avea un impact major asupra interfeței grafice (UI) și a modului de utilizare (user flow).
O etapă importantă este împărțirea specificațiilor în User Stories (splitting), în cadrul unei alte pagini Confluence. Aceasta se face de către BA în colaborare cu TL care adaugă, cu această ocazie, detaliile tehnice, în special cele legate de noul framework (care nu se pot extrage prin inginerie inversă din codul sursă existent).
În acest punct, rămâne să se alimenteze backlogul proiectului care, în urma ședințelor de refinement și estimare, ajunge în Sprint backlog.
Așadar, în cadrul acestui proiect, însuși rolul de analist a suferit modificări și a fost adaptat constant la nevoile curente. În consecință, o parte dintre activitățile desfășurate de analist, în cazul de față, sunt caracteristice unui BA, pe când o altă parte sunt mai apropiate de rolul unui Systems Analyst. În diagrama de mai jos se poate observa diferența dintre abilitățile și responsabilitățile standard ale unui BA și cele ale unui Systems Analyst.
În cadrul proiectului prezentat, abilitățile cele mai importante pentru BA, în ordinea importanței, sunt: rezolvarea problemelor, elicitarea, înțelegerea conceptelor tehnice și comunicarea.
Această adaptare a analiștilor, de la rolul de Business Analyst, îndeplinit în proiectele precedente, către sfera de activitate a unui Systems Analyst, este o urmare a feedbackului oferit constant de echipă și a îmbunătățirii procesului de lucru.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
