Meny

Rollen for forretningsanalytikere i SCRUM og hvorfor er en kvalitetssikring best for denne rollen?

  • Hoved
  • Agile Testing
  • Rollen for forretningsanalytikere i SCRUM og hvorfor er en kvalitetssikring best for denne rollen?

role business analysts scrum

selen finne element av css selector

Prøv Instrumentet Vårt For Å Eliminere Problemer

Fremtredende rolle for forretningsanalytikere i SCRUM:

En forretningsanalytiker som kort omtales som en BA spiller en veldig drastisk og viktig rolle i SKRUM .

Denne personen er koblingen mellom produkteieren / kunden og det tekniske IT-teamet. Selv om vi har kommet over flere opplæringsprogrammer på nettstedet vårt om BA, vil denne opplæringen på en eller annen måte være unik og vil forklare deg viktigheten av BA i SCRUM.

La oss utforske !!

=> Sjekk ALLE opplæringer for forretningsanalytikere her.

Rolle av forretningsanalytikere i SCRUM og hvorfor er en kvalitetssikring best for denne rollen_

Hva du vil lære:

Ansvar for en BA

Det er flere roller for forretningsanalytikere i Scrum, og det er visse ansvarsområder som en BA skal følge.

Få selektive blant dem er nevnt nedenfor.

  • Pleie av etterslep av produktet basert på prioriteringen fra produkteieren.
  • Analyse av kundens behov og finne løsninger for å imøtekomme dem.
  • Lage kravene i form av brukerhistorier med passende akseptkriterier.
  • Hvis brukerhistoriene allerede er opprettet av produkteieren (med akseptkriterier), må du gjennomgå dem for å sikre at alle forretningsregler er dekket og akseptkriteriene oppfyller brukerhistoriens funksjonalitet.
  • Arbeide med produkteieren og interessentene for å forstå omfanget, foreslå forbedringer i kravene, etc.
  • Klargjøre dokumenter som trådrammer, designflyt, brukergrensesnitt osv., Når og når det er nødvendig.

Bortsett fra dette, a Forretningsanalytiker er en viktig deltaker i idédugnadene når laget møtes for å diskutere den kommende sprintens etterslep. BA veileder teamet, hjelper dem til å forstå kravene, og må til og med godkjenne implementeringen.

Han arbeider også tett med kvalitetssikringene som å analysere testdekningen, konvertere brukssaker i virkeligheten til testsaker, gi innsikt i å teste komplekse funksjoner osv. BA deltar også i planleggingsmøtet for å hjelpe teamet i estimeringer ved å hjelpe dem forstå flyt, kompleksitet og avhengighet.

BA må alltid fortsette å lære om den nye trenden som foregår i markedet, holde innovasjoner og holde seg oppdatert om forretningsområdet som produktet er laget for.

BA

Forretningsanalytiker som produkteier

Avhengig av kunden og selskapet, hender det at noen selskaper har Business Analyst som produktseier. I disse tilfellene er BA kontaktpunktet for alle spørsmålene. BA blir deretter megler mellom teamet og interessentene.

BA må forstå kravene til interessentene, deres tenkning om å ta virksomheten fremover, og hva (og hvordan) virksomheten skal vokse. Basert på kravene fra interessentene, må BA opprette dokumentene, brukerhistoriene, prioritere historiene, hjelpe teamet til å forstå dem, svare på spørsmålene deres om det samme, etc.

Det viktigste å merke seg her er at dette er tilrådelig når BA er fysisk tilgjengelig og ikke er geolokalisert til en annen tidssone for å unngå ‘gap in communication’.

Hvis BA som i produkteieren er geolokalisert til en annen tidssone, er det ikke mulig å nærme seg ham hver gang, og den eneste måten å kommunisere på er via e-post eller chatter eller samtaler, og dette kan føre til mangel, gap og til og med feilkommunikasjon til tider.

I følge min erfaring bør dette følges når BA sitter på kontoret ditt, ved siden av teamet ditt, slik at arbeidet ditt ikke hindrer og (e) han lett kan nås. Fra BAs synspunkt eier de produktet på vegne av interessentene / kundene, tar passende beslutninger og trenger til og med å lære seg nye ferdigheter, som kan omfatte å lære noen tekniske utviklingsmuligheter.

Å ha en forretningsanalytiker som produkteier er en ekstra fordel fordi forretningsanalytikeren forstår produktet veldig godt, og det kan også forhandles om prioritering og omfang av oppgaver.

BA-PO

Forretningsanalytiker som teammedlem

Det andre alternativet er å ha forretningsanalytikeren som et teammedlem fordi produkteieren ikke vil være tilgjengelig hver gang. Når forretningsanalytikeren er et teammedlem, hjelper de jevnaldrende i forsinkelsespleie.

Å ha en forretningsanalytiker som et teammedlem er mer fordelaktig fordi det tekniske teamet synes det er enkelt og behagelig å kommunisere med BA for avklaringer eller diskusjoner. BA jobber også tett med QA-teamet for testing, dvs. å analysere dekningen, brukssakene dekket, eventuelle skjulte krav eller pålitelighet eller effekter.

Noen ganger kan akseptkriteriene som er skrevet av produkteieren være vage og ikke klare. Da blir det som teammedlem BAs ansvar å skrive forseggjorte og godt forklarte akseptkriterier. Hvis teamet trenger mer informasjon, oppretter BA også trådrammedokumenter, flytdokumenter osv. For å hjelpe teamet til å forstå kravene.

I storskala prosjekter der modulene er fordelt på team, er det også en ekstra fordel å ha en BA for mer enn ett team. Siden BA er den samme på tvers av team, kan han tenke på interoperabiliteten til modulene, hvordan nye funksjoner eller oppdateringer vil påvirke de andre modulene, etc.

Dermed vil dette hjelpe tekniske team til å vurdere slike aspekter som ikke alltid brukerhistoriene eller akseptkriteriene nevner slike.

BA_Team-medlem

Viktigheten og rollen til forretningsanalytikere i SCRUM Team

Rollen til forretningsanalytikere i SCRUM er veldig viktig for å lykkes med et prosjekt. Engasjementet deres starter rett fra å forstå kundens behov til Sprint Demo. De er det første kontaktpunktet for teknisk team for avklaringer. De er enda viktigere i de innledende fasene av et nytt prosjekt og prosjektene som er store i skala.

Produkteieren vil ikke alltid være en god forfatter, noen ganger kommer de fra en teknisk bakgrunn, og det blir derfor forretningsanalytikerens ansvar å skrive historiene, aksept, trådrammer osv.

I prosjektet mitt var PO-en vår ikke så god med dokumentasjon, og til og med brukerhistoriene som ble skrevet var aldri mer enn 2-3 linjere, mens akseptkriteriene bare var en liner. Det var forretningsanalytikeren som pleide å modifisere dem, gjøre dem mer forklarende og forseggjorte.

Selv til tider skjedde det at vår PO skrev brukerhistorier som hadde 21 eller flere historiepoeng, og derfor måtte forretningsanalytikeren bruke ekstra tid og krefter på å bryte dem ned og prioritere dem med produkteieren.

Du kan forestille deg hva som ville skje hvis det ikke er noen forretningsanalytiker og produkteieren din har opprettet en brukerhistorie som 'Som kunde vil jeg utføre alle bankoperasjoner for kontoen min', med akseptkriterier som:

  1. Kunden skal kunne logge på.
  2. Kunden skal kunne gjøre transaksjoner på kontoen min.
  3. Kunden skal kunne laste ned mine historiske uttalelser osv.

Nå, etter min mening, vil denne brukerhistorien inneholde enda mer enn 34 historiepoeng, og det er derfor behov for å bryte den ned ytterligere. Ting vil forverres for det tekniske teamet hvis de riktige flytskjemaene og UI-skjermene (som skal opprettes) ikke er gitt.

Dette ville føre til en sviktende sprint, og i sin tur et mislykket prosjekt. Med mindre produkteieren er en utdannet / praktisert forretningsanalytiker, er det behov for å ha en på teamet.

Hvorfor passer en QA best for denne jobben?

QA er en person som verifiserer den foreslåtte løsningen for et problem / krav ved å teste det. Derfor er forretningsanalytikere / interessenter / produkteiere veldig ivrige etter å vite om tilbakemeldinger fra en kvalitetssikring. Engasjementet fra en BA i testing er lite mer enn hva det er i utvikling.

En forretningsanalytiker arbeider tett med en kvalitetssikring for å gjennomgå testdekningsdekningen som gir et innblikk i skjulte strømmer eller krav / effekter. Dermed får denne typen kunnskapsdeling (av BA) dem til å forstå produktfunksjonaliteten, forretningsreglene, kundens forventninger, flyter, avhengigheter og alt helt.

QA tester alltid fra sluttkunden som vil bruke produktet, derav er sjansene for å hjelpe kunden med forbedringer, forbedringer i produktet mer (sammenlignet med en utvikler). Utviklere utvikler produktet for den gitte brukerhistorien og settet med akseptkriterier, men tenker ikke alltid på hvordan en kunde vil bruke produktet .

I utviklingen er implementeringen av et produkt, flyten og reglene godt definert, men testing er helt basert på logisk tenking og evnen til å tenke fra sluttbrukernes synspunkt.

QA kan begynne å komme inn i rollen som forretningsanalytikere i SCRUM på grunn av mange muligheter som blir presentert i det daglige arbeidet.

Anbefalt lese => Karriereforskyvning fra en tester til BA

Det er veldig enkelt for en kvalitetssikring å komme inn i rollene som:

  • Studer kravene veldig dypt og pek på hullene i gjennomgangsmøter / idédugnad osv. Prøv å tenke bedre løsninger og diskuter det samme med teamet og BA.
  • Vær oppmerksom på samtaler med produkteieren, still spørsmål og del dine funn. Dette vil øke tilliten til produkteieren som viser din interesse for produktet.
  • Passer deg mellom BA og utviklingsteamet, du bør være kontaktpunktet for utviklerne i tilfelle avklaringer eller tvil.
  • Sett opp testprosessen og fortsett å innovere den, og endre den for å hjelpe til med å levere vellykkede sprints.
  • Når det gjelder produkter med fancy brukergrensesnitt, må du se etter nye trender og foreslå slike forbedringer.
  • Forstå produktet helt inn og ut.
  • Bygg sterk kunnskap om dine interessenter, deres forventninger, og del din erfaring med dem.

Dette innebærer også at for å komme inn i BA-rollen må du forbedre dine ferdigheter. Flere kurs som inkluderer både grunnnivå og avansert nivå finnes i markedet.

Er du en BA / QA? Har vi med rette påpekt alt om din rolle? Eller tror du vi har savnet noe du unikt utfører? Vi hører gjerne fra deg. Del dem gjerne med oss ​​i kommentarfeltet nedenfor !!

=> Besøk her for å se Business Analyst-serien for alle.

Anbefalt lesing

^