ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 120
Abonament PDF

The scent of the rose - adaptarea rolului de BA în contextul rescrierii unui sistem complex

Andreea Zdrobau
Middle Business Analyst @ PitechPlus



Floris Cosmin Pop
Senior Business Analyst @ PitechPlus
MANAGEMENT

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.

Bibliografie

  1. The Roles and Skill Sets of Systems vs Business Analysts, 19th Australasian Conference on Information Systems

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA