role business analysts scrum
întrebări și răspunsuri la interviu cu seleniu pentru experimentați
Rolul proeminent al analiștilor în afaceri în SCRUM:
Un analist de afaceri numit în scurt timp BA are un rol foarte drastic și important în SCRUM .
Această persoană este legătura dintre proprietarul produsului / client și echipa tehnică IT. Deși am întâlnit mai multe tutoriale pe site-ul nostru de pe BA, acest tutorial va fi cumva unul unic și vă va explica importanța BA în SCRUM.
Să explorăm !!
=> Consultați TOATE Tutorialele Business Analyst aici.
Ce veți învăța:
- Responsabilitățile unui BA
- Analist de afaceri ca proprietar de produs
- Analist de afaceri ca membru al echipei
- Importanța și rolul analiștilor în afaceri în echipa SCRUM
- De ce este cel mai potrivit un QA pentru acest loc de muncă?
- Lectură recomandată
Responsabilitățile unui BA
Există mai multe roluri ale analiștilor în afaceri în Scrum și există anumite responsabilități la care ar trebui să respecte un BA.
Puține dintre cele selective sunt menționate mai jos.
- Îngrijirea restanțelor produselor pe baza priorităților oferite de proprietarul produsului.
- Analizând nevoile clienților și găsind soluțiile pentru a le aborda.
- Crearea cerințelor sub formă de povești ale utilizatorilor cu criterii de acceptare adecvate.
- Dacă în cazul în care poveștile utilizatorilor au fost deja create de proprietarul produsului (cu criterii de acceptare), revizuirea acestora pentru a vă asigura că fiecare regulă de afaceri este acoperită și că criteriile de acceptare îndeplinesc funcționalitatea poveștii utilizatorului.
- Colaborarea cu proprietarul produsului și cu părțile interesate pentru a înțelege domeniul de aplicare, pentru a sugera îmbunătățiri ale cerințelor etc.
- Pregătirea documentelor cum ar fi wireframe, fluxul de proiectare, interfața de utilizare etc., după cum este necesar.
În afară de aceasta, a Analist de afaceri este un participant important la sesiunile de brainstorming atunci când echipa se întâlnește pentru a discuta restanța viitoare a sprintului. BA îndrumă echipa, îi ajută să înțeleagă cerințele și chiar uneori trebuie să aprobe implementarea.
De asemenea, lucrează îndeaproape cu QA-urile, cum ar fi analizarea acoperirii testelor, transformarea cazurilor de utilizare din lumea reală în cazuri de testare, oferind informații pentru testarea funcționalităților complexe, etc. BA participă, de asemenea, la întâlnirea de planificare pentru a ajuta echipa în estimări, ajutându-i să să înțeleagă fluxul, complexitatea și dependența.
BA trebuie să continue să învețe despre noua tendință care se întâmplă pe piață, să continue să inoveze și să rămână la curent cu privire la zona de afaceri pentru care a fost produs produsul.
Analist de afaceri ca proprietar de produs
În funcție de client și companie, se întâmplă ca unele companii să aibă Business Analyst ca proprietar al produsului. În aceste cazuri, BA este punctul de contact pentru toate interogările. BA devine apoi mediator între echipă și părțile interesate.
BA trebuie să înțeleagă cerințele părților interesate, gândirea lor de a duce afacerea înainte și ce (și cum) ar trebui să crească afacerea. Apoi, pe baza cerințelor părților interesate, BA trebuie să creeze documentele, poveștile utilizatorilor, să acorde prioritate poveștilor, să ajute echipa să le înțeleagă, să răspundă la întrebările lor despre aceleași etc.
Cel mai important lucru de remarcat aici este că acest lucru este recomandabil atunci când BA este disponibil din punct de vedere fizic și nu este geolocalizat într-un alt fus orar, astfel încât să se evite „decalajul în comunicare”.
Dacă BA, ca la proprietarul produsului, este geolocalizat la un fus orar diferit, atunci nu este posibil să îl abordați de fiecare dată și singurul mod de a comunica este prin e-mailuri, chaturi sau apeluri, prin urmare, acest lucru poate duce la lipsă, lacune și chiar comunicare greșită uneori.
Conform experienței mele, acest lucru ar trebui urmat atunci când BA este în biroul dvs., lângă echipa dvs., astfel încât munca dvs. să nu vă împiedice și (i) să fie ușor accesibil. Din punctul de vedere al BA, ei dețin produsul în numele părților interesate / clienților, iau decizii adecvate și chiar au nevoie să învețe noi abilități care pot include învățarea unor tehnicități de dezvoltare.
A avea un Business Analyst ca proprietar de produs este un avantaj suplimentar, deoarece Business Analyst înțelege foarte bine produsul, iar prioritizarea și sfera sarcinilor pot fi negociate, de asemenea.
Analist de afaceri ca membru al echipei
Cealaltă opțiune este să aveți Business Analyst ca membru al echipei, deoarece proprietarul produsului nu va fi disponibil de fiecare dată. Atunci când Business Analyst este un membru al echipei, atunci îi ajută pe colegii lor în îngrijirea restantei.
A avea un analist de afaceri ca membru al echipei este mai avantajos, deoarece echipei tehnice îi este ușor și confortabil să comunice cu BA pentru clarificări sau discuții. De asemenea, BA lucrează îndeaproape cu echipa QA pentru testare, adică analiza acoperirii, cazurilor de utilizare acoperite, orice cerințe ascunse sau fiabilitate sau efecte.
Uneori, criteriile de acceptare scrise de proprietarul Produsului pot fi vagi și nu sunt clare, apoi, ca membru al echipei, devine responsabilitatea BA să scrie criterii de acceptare elaborate și bine explicate. Dacă echipa are nevoie de mai multe informații, atunci BA creează, de asemenea, documente wireframe, documente de flux etc. pentru a ajuta echipa să înțeleagă cerințele.
În proiectele la scară largă în care modulele sunt distribuite între echipe, deținerea unui BA pentru mai multe echipe este, de asemenea, un avantaj suplimentar. Întrucât BA este același între echipe, se poate gândi la interoperabilitatea modulelor, modul în care noile caracteristici sau actualizări vor afecta celelalte module etc.
Astfel, acest lucru ar ajuta foarte mult echipele tehnice să ia în considerare astfel de aspecte, deoarece nu întotdeauna poveștile utilizatorilor sau criteriile de acceptare menționează astfel.
Importanța și rolul analiștilor în afaceri în echipa SCRUM
Rolul analiștilor în afaceri în SCRUM este foarte important în succesul unui proiect. Implicarea lor începe chiar de la înțelegerea nevoii clientului la Sprint Demo. Ele sunt primul punct de contact pentru echipa tehnică pentru clarificări. Acestea sunt și mai importante în fazele inițiale ale unui nou proiect și în proiectele de dimensiuni mari.
Proprietarul de produs nu va fi întotdeauna un scriitor bun, uneori provin dintr-un mediu tehnic și, prin urmare, devine responsabilitatea analistului de afaceri să scrie poveștile, acceptarea, wireframe-uri etc.
În proiectul meu, PO-ul nostru nu a fost atât de bun în ceea ce privește documentația și chiar și poveștile utilizatorilor scrise nu au fost niciodată mai mari de 2-3 linere, în timp ce criteriile de acceptare erau doar 1 linie. Analistul de afaceri a fost cel care le-a modificat, le-a făcut mai explicative și mai elaborative.
Chiar și uneori, s-a întâmplat ca PO-ul nostru să scrie articole de utilizator care să aibă 21 sau mai multe puncte de poveste și, prin urmare, Business Analyst a trebuit să cheltuiască timp și eforturi suplimentare pentru a le descompune și a le acorda prioritate proprietarului de produs.
Vă puteți imagina ce s-ar întâmpla dacă nu există un analist de afaceri și proprietarul dvs. de produs ar fi creat o poveste de utilizator precum „În calitate de client, vreau să efectuez toate operațiunile bancare pentru contul meu”, cu criterii de acceptare precum:
- Clientul ar trebui să se poată autentifica.
- Clientul ar trebui să poată face tranzacții în contul meu.
- Clientul ar trebui să poată descărca declarațiile mele istorice etc.
Acum, după părerea mea, această poveste a utilizatorului ar conține chiar mai mult de 34 de puncte de poveste, prin urmare este nevoie să o descompunem în continuare. Lucrurile s-ar înrăutăți pentru echipa tehnică dacă nu sunt furnizate diagramele de flux corespunzătoare și ecranele UI (care urmează să fie create).
Acest lucru ar duce la un sprint eșuat și, la rândul său, la un proiect eșuat. Cu excepția cazului în care proprietarul de produs este un analist de afaceri instruit / practicat, este necesar să aveți unul în echipă.
De ce este cel mai potrivit un QA pentru acest loc de muncă?
QA este o persoană care verifică soluția propusă pentru o problemă / cerință testând-o. Prin urmare, analistul de afaceri / părțile interesate / proprietarii de produse sunt foarte dornici să afle despre feedback-ul unui QA. Implicarea unui BA în testare este puțin mai mult decât ceea ce este în dezvoltare.
Un analist de afaceri lucrează îndeaproape cu un QA în revizuirea acoperirii cazurilor de testare, care oferă o perspectivă asupra fluxurilor ascunse sau a cerințelor / efectelor. Astfel, acest tip de schimb de cunoștințe (de către BA) îi face să înțeleagă complet funcționalitatea produsului, regulile de afaceri, așteptările clienților, fluxurile, dependențele și totul.
QA testează întotdeauna din punctul de vedere al clientului final care ar folosi produsul, de aceea șansele de a ajuta clientul pentru îmbunătățiri, îmbunătățirile produsului sunt mai multe (în comparație cu un dezvoltator). Dezvoltatorii dezvoltă produsul pentru povestea utilizatorului dat și setul de criterii de acceptare, dar nu întotdeauna se gândesc la modul în care un client ar folosi produsul .
În curs de dezvoltare, implementarea unui produs, fluxul și regulile sunt bine definite, dar testarea se bazează complet pe gândirea logică și capacitatea de a gândi din punctul de vedere al utilizatorilor finali.
QA poate începe să intre în rolul analistilor de afaceri în SCRUM din cauza multor oportunități care sunt prezentate în activitatea de zi cu zi.
Citiți recomandat => Schimbarea carierei de la un tester la BA
Este foarte ușor pentru un QA să intre în roluri precum:
- Studiați cerințele foarte profund și evidențiați lacunele din reuniunile de revizuire / sesiunile de brainstorming etc. Încercați să vă gândiți la soluții mai bune și să discutați aceleași cu echipa și BA.
- Fiți atent la apelurile cu proprietarul produsului, puneți întrebări și împărtășiți constatările dvs. Acest lucru va spori încrederea proprietarului produsului, arătându-vă interesul pentru produs.
- Așezați-vă între BA și echipa de dezvoltare, ar trebui să fiți punctul de contact pentru dezvoltatori în caz de clarificări sau îndoieli.
- Configurați procesul de testare și continuați să îl inovați, schimbându-l pentru a ajuta la livrarea sprinturilor de succes.
- În cazul produselor cu IU de lux, căutați noi tendințe și sugerați astfel de îmbunătățiri.
- Înțelegeți produsul complet în interior și în exterior.
- Construiți o cunoaștere puternică a părților interesate, așteptărilor acestora și împărtășiți-le experiența.
Acest lucru implică, de asemenea, că, pentru a intra în rolul de BA, trebuie să vă îmbunătățiți abilitățile. Pe piață se găsesc mai multe cursuri care includ atât nivelul de bază, cât și nivelul avansat.
Sunteți BA / QA? Am subliniat pe bună dreptate totul despre rolul tău? Sau crezi că am ratat ceva ce executați în mod unic? Am fi bucuroși să aflăm de la dvs. Simțiți-vă liber să ni le împărtășiți în secțiunea de comentarii de mai jos !!
=> Vizitați aici pentru a vedea seria Business Analyst pentru toți.
Lectură recomandată
- Artefacte Scrum: Backlog de produse, Backlog Sprint și Incrementări de produse
- Există vreo limită de pornire și oprire a rolului QA în Scrum?
- 39 de cele mai bune instrumente de analiză a afacerii utilizate de cei mai buni analisti de afaceri (lista A la Z)
- Roluri și responsabilități ale echipei Scrum: Scrum Master și proprietar de produs
- Schimbarea carierei de la un tester la analist de afaceri - un ghid pas cu pas
- Kick Start Your Career as a Business Analyst: A Career Avenue for You
- Suport IT și Dezvoltare Afaceri Coordonator Executiv Cum Training Pune
- Defect Triaging în Scrum: Cum este organizat într-o configurare Scrum