După cum îți ziceam în articolul ”The end of an era” de ceva timp am părăsit Premium Softwares iar noile provocări le voi aveam în cadrul Centric Romania ca Business Analyst. Pe motivul ăsta în cele ce urmează voi avea o serie de articole despre procesul de adunare de cerințe și chestii adiacente acestui lucru. Poți arunca o privire și pe articolul despre ”Uncertainty of requirements” pentru un mic preambul.
Ca software developer scopul a ceea ce livrezi e ca totalitatea codului scris să acopere câteva arii ca performanța, scalabilitatea, stabilitatea, adaptabilitatea și eventual raportului dintre cost/beneficiu al produsului software. Cost/beneficiu se referă mai mult ca timp de dezvoltare și complexitatea pentru că în general ca developer nu prea te interesează costul în bani asociat feature-ului dezvoltat.
O componentă esențială în dezvoltare software este înțelegerea cerințelor clientului în totalitate (sau cel puțin un procent destul de mare), înțelegerea filosofiei de viață a companiei care folosește softul produs de tine, modul în care interacționează diverse departamente în cadrul companiei. În general pentru developeri acest lucru nu este o prioritate și câteodată chiar generează dureri de cap, ca developer axându-te mai mult pe partea tehnică decât pe cea de business. Așadar scopul unui BA este de a crea o mai bună înțelegere a necesităților business-ului pentru a contribui la un proces de dezvoltare de succes.
De ce există nevoie de a avea requirements? Scopul de bază al acestora este de a identifica potențiala problemă, a o înțelege în profunzime și a găsi soluții pentru rezolvarea ei. Un motiv adițional este de a scădea costul proiectului prin micșorarea costului legat de refacerea muncii deja efectuate.
Orice proiect are câteva etape care pot fi definite cam așa: definire, adunare cerințe, design și arhitectură, dezvoltare și testare, livrare.
Scoping este faza în care se face estimarea efortului și a impactului pe care dezvoltarea acestui feature îl poate avea. Putem să spunem că este o fază de tatonare și descriere la nivel neexhaustiv a proiectului.
Adunare cerințe, cred că numele este destul de sugestiv, este a doua fază, fază în care se captează cât mai mult din detaliile proiectului și se crează consens între toți stakeholderii de la acest nivel asupra a ceea ce trebuie realizat în următoarele etape. Efortul BA-ului este cel mai considerabil în această fază.
Design și arhitectură, este faza în care echipa tehnică (arhitecți, developeri, testeri) crează un framework pentru designul soluției tehnice alese. În acest punct s-ar putea ca nu toate detaliile problemei să fie cunoscute însă cel puțin ar trebui setate acum liniile mari de design. Tot aici se face o estimare mai în detaliu a estimărilor de cost, timp, oameni implicați.
Dezvoltare și testare, nu intru în detalii deloc aici. Ce trebuie să punctez e că în această etapă este posibil să apară modificări a celor decise în faza anterioară.
Livrare, este etapa în care se face migrarea soluției tehnice dezvoltate către client, se migrează date și aplicații, se instalează hardware. Aici, BA-ul face training clientului și end-userilor care uneori sunt persoane diferite față de client.
Dacă se urmează una dintre metodologiile agile, aceste etape pot fi făcute în același timp.
