Filozofia Agile a pornit de la un manifest de patru principii dedicate echipelor de software development. În timp, aceasta a crescut considerabil și s-a dezvoltat în diferite frameworkuri, înlocuind în final tradiționala metodologie Waterfall.
Faptul că în Agile nu vedem definit un rol de business analyst, cum de altfel nu vedem definite multe roluri în afara celor tehnice, este pentru că aceasta ar încălca principiul Agile fundamental : colaborarea. Metodologia nu reprezintă în sine un proces de analiză a nevoilor de business, ci un proces de software development gândit să aducă cât mai multă valoare businessului.
Da și nu. Echipele Agile ar trebui, teoretic, să fie cross funcționale și capabile să se organizeze atât de bine încât să poată livra un proiect end-to-end. Și de cele mai multe ori sunt așa, mai ales dacă avem implicat un Product Owner (PO). Totuși, realitatea este diferită și deseori, PO-ul reprezintă clientul, iar echipa de development nu are resurse pentru a acoperi atât identificarea nevoilor de business, cât și obținerea și documentarea cerințelor. Un BA integrat în echipa de software development cunoaște contextul proiectului, mecanismele care ar putea face munca echipei mai eficientă, dar mai ales colaborează și aliniază stakeholderii interni și externi - pe care nu e mereu ușor să îi găsești disponibili.
Definirea nevoilor de business și documentarea lor:
Cunoașterea și definirea nevoilor de business este un pas important în perioada de descoperire și analiză a oricărui proiect, atunci când vorbim de custom software development.
Nevoile reale pot fi diferite de cele percepute inițial. De aceea, intervine BA-ul care lucrează îndeaproape cu clientul și alege o abordare adecvată pentru definirea scopului, indiferent dacă nevoile de business sunt concentrate pe probleme sau oportunități.
Scrierea de User stories (US) diferă de la organizație la organizație și depinde mult de proiect. Conform multor frameworkuri Agile, aceasta poate fi o responsabilitate care alternează între BA și PO, însă aportul adus de un BA este să le alinieze la criteriile INVEST - să se asigure că sunt independente, negociabile, valoroase, estimabile, dimensionate corect și testabile. Rafinarea US are loc împreună cu echipa de development la sfârșitul unui sprint și are ca scop pregătirea backlogului pentru sprintul următor.
Frameworkurile Agile sunt create pentru a minimiza efortul și a maximiza rezultatele obținute. Prin urmare, prioritizarea joacă un rol foarte important. Cum schimbarea constantă ce revine odată cu descoperirea de noi informații are impact asupra backlogului, e nevoie de o persoană care să cunoască foarte bine industria, nevoile clientului și statusul proiectului pentru a putea pune cap la cap informațiile și a putea face recomandări pentru prioritizare.
Într-o echipă experimentată în lucrul Agile, un BA se regăsește intermediind conversații și decizii dificile între stakeholderi. Acest rol poate fi unul ambiguu în metodologia Agile, dar un lucru e clar: un BA obține și oferă informațiile potrivite la momentul potrivit astfel încât dezvoltarea proiectului să prospere. Această responsabilitate de clarificare sintetizează foarte bine întrebarea cel mai des adresată de către un BA: cum pot să ajut? Un BA va fi acolo să se asigure că toți cei implicați în proiect au toate informațiile necesare pentru a putea să-și facă treaba cât mai bine, e acolo să clarifice atât nelămuririle privind statusul proiectului pentru client, cât și întrebările echipei privind flowul de business.
O altă responsabilitate importantă a unui BA este să se asigure că în cadrul fiecărui US avem definite acceptance criteria înainte de implementare. Aceste criterii de acceptare descriu, de fapt, limitările funcționalităților și regulile care servesc ca punct de plecare pentru construirea cazurilor de testare de către Quality Assurer (QA). Cât despre User Acceptance Testing (UAT), este pasul final în orice proiect de software development - momentul în care utilizatorii testează software-ul și validează schimbările dacă acestea le îndeplinesc nevoile reale. Un BA participă activ în planificarea și efectuarea UAT pentru a se asigura că proiectul livrat aduce într-adevăr valoare.
În compania noastră, distribuția set-up-ului echipei per proiect conține în proporție de 80% și alocarea unui BA atunci când vorbim de software development. Dacă vorbim de presales, echipele pe care le numim Client Engagement Team sunt întotdeauna o combinație UX + BA + Solution Architect, foarte importantă în această fază inițială de discovery. Obiectivul nostru este de a participa în mod activ la munca în echipă de și a avea echipe cât mai independente care să lucreze eficient, deschis și transparent.
Așadar, rolul de BA a fost mereu unul Agile. Necesită colaborare, adaptare constantă, acceptare a schimbării, leadership și empatie. Chiar dacă pare dificil să explicăm toate aceste responsabilități bunicilor, pe scurt, un BA este liantul dintre client și echipa tehnică. Cea mai des întâlnită întrebare pe care o vei primi de la un BA este: ,,Cum pot să ajut?"
de John Bax
de Dan Suciu
