Menú

El paper dels analistes de negocis a SCRUM i per què és millor un control de qualitat per a aquest paper?

  • Principal
  • Proves Àgils
  • El paper dels analistes de negocis a SCRUM i per què és millor un control de qualitat per a aquest paper?

role business analysts scrum

per a què s’utilitza la programació c ++

Proveu El Nostre Instrument Per Eliminar Problemes

Rol destacat dels analistes de negocis a SCRUM:

Un analista de negocis que en breu es coneix com a BA té un paper molt dràstic i important a SCRUM .

Aquesta persona és l'enllaç entre el propietari del producte / client i l'equip tècnic de TI. Tot i que hem trobat diversos tutorials al nostre lloc web sobre BA, aquest tutorial serà d'alguna manera únic i us explicarà la importància de BA en SCRUM.

Explorem !!

=> Consulteu aquí TOTS els tutorials de Business Analyst.

Paper dels analistes de negocis a SCRUM i per què és millor un QA per a aquest rol_

Què aprendreu:

Responsabilitats d'un BA

Hi ha diversos rols d’analistes empresarials a Scrum i hi ha certes responsabilitats a les quals hauria de complir un BA.

A continuació, se’n mencionen poques de selectives.

  • Preparació de la cartera de productes basada en la priorització proporcionada pel propietari del producte.
  • Analitzar les necessitats del client i trobar les solucions per atendre-les.
  • Crear els requisits en forma d’històries d’usuaris amb els criteris d’acceptació adequats.
  • Si en cas que les històries dels usuaris hagin estat creades pel propietari del producte (amb criteris d'acceptació), reviseu-les per assegurar-vos que totes les regles empresarials estan cobertes i que els criteris d'acceptació compleixen la funcionalitat de la història de l'usuari.
  • Treballar amb el propietari del producte i els grups d'interès per entendre l'abast, suggerir millores als requisits, etc.
  • Preparació de documents com a wireframes, flux de disseny, interfície d’usuari, etc., quan i quan sigui necessari.

A part d'això, a Analista de negoci és un participant important en les sessions de pluja d’idees quan l’equip es reuneix per debatre l’endarreriment del proper sprint. El BA guia l'equip, els ajuda a entendre els requisits i, fins i tot, de vegades ha d'aprovar la implementació.

També treballa estretament amb els QA com analitzar la cobertura de les proves, convertir casos d’ús del món real en casos de prova, proporcionar informació per provar funcionalitats complexes, etc. El BA també participa a la reunió de planificació per ajudar l’equip a fer estimacions ajudant-los a entendre el flux, la complexitat i la dependència.

BA ha de seguir aprenent sempre sobre la nova tendència que està succeint al mercat, seguir innovant i estar al dia sobre l’àrea de negoci per a la qual s’ha fabricat el producte.

BA

Analista de negocis com a propietari de producte

Depenent del client i de l’empresa, passa que algunes empreses tenen l’analista comercial com a propietari del producte. En aquests casos, el BA és el punt de contacte per a totes les consultes. El BA es converteix llavors en el mediador entre l'equip i els grups d'interès.

El BA ha d'entendre els requisits dels grups d'interès, el seu pensament per tirar endavant el negoci i què (i com) hauria de créixer el negoci. A continuació, en funció dels requisits dels grups d'interès, el BA ha de crear els documents, les històries dels usuaris, prioritzar les històries, ajudar l'equip a entendre-les, respondre a les seves preguntes sobre les mateixes, etc.

El més important que cal tenir en compte aquí és que això és aconsellable quan el BA està disponible físicament i no està geolocalitzat a una zona horària diferent per evitar el 'buit en la comunicació'.

Si el BA com el propietari del producte està geolocalitzat a una zona horària diferent, no és possible acostar-s'hi cada vegada i l'única manera de comunicar-se és mitjançant correus electrònics, xats o trucades, de manera que això pot resultar en manca, bretxa i fins i tot de vegades la mala comunicació.

Segons la meva experiència, s’hauria de seguir quan el BA estigui assegut al vostre despatx, al costat del vostre equip, de manera que el vostre treball no dificulti i (s) sigui fàcilment accessible. Des del punt de vista de BA, són propietaris del producte en nom de les parts interessades / clients, prenen decisions adequades i fins i tot necessiten aprendre noves habilitats que poden incloure l’aprenentatge d’alguns aspectes tècnics del desenvolupament.

Tenir un Business Analyst com a propietari de producte és un avantatge afegit perquè Business Analyst entén molt bé el producte i també es pot negociar la priorització i l'abast de les tasques.

BA-PO

Analista de negocis com a membre de l’equip

L’altra opció és comptar amb Business Analyst com a membre de l’equip perquè el propietari del producte no estarà disponible cada vegada. Quan Business Analyst és membre de l’equip, ajuden els companys a preparar-se.

Tenir un analista de negocis com a membre de l’equip és més avantatjós perquè a l’equip tècnic li resulta fàcil i còmode comunicar-se amb el BA per obtenir aclariments o discussions. El BA també treballa estretament amb l'equip de control de qualitat per provar, és a dir, analitzar la cobertura, els casos d'ús coberts, els requisits ocults o la fiabilitat o els efectes.

De vegades, els criteris d’acceptació escrits pel propietari del producte poden ser poc definits i, per tant, com a membre de l’equip, la responsabilitat del BA és escriure criteris d’acceptació elaborats i ben explicats. Si l'equip necessita més informació, el BA també crea documents wireframe, documents de flux, etc. per ajudar l'equip a entendre els requisits.

En els projectes a gran escala on els mòduls es distribueixen entre equips, tenir un BA per a més d’un equip també és un avantatge afegit. Com que el BA és el mateix entre equips, pot pensar en la interoperabilitat dels mòduls, en com afectaran les noves funcions o actualitzacions als altres mòduls, etc.

Per tant, això ajudaria molt als equips tècnics a considerar aspectes com que no sempre es mencionen les històries dels usuaris o els criteris d'acceptació.

Membre de BA_Team

Importància i paper dels analistes de negocis a l’equip SCRUM

El paper dels analistes de negocis a SCRUM és molt important per a l'èxit d'un projecte. La seva participació comença des de la comprensió de la necessitat del client fins a la demostració Sprint. Són el primer punt de contacte de l'equip tècnic per obtenir aclariments. Són encara més importants en les fases inicials d’un nou projecte i en els projectes a gran escala.

El propietari del producte no sempre serà un bon escriptor, de vegades prové de formació tècnica i, per tant, passa a ser responsabilitat de Business Analyst escriure les històries, l’acceptació, els telèfons mòbils, etc.

Al meu projecte, el nostre PO no era tan bo amb la documentació i fins i tot les històries dels usuaris escrites mai van superar els 2-3 revestiments, mentre que els criteris d’acceptació eren només 1 revestiment. Va ser l’analista empresarial qui solia modificar-los, fer-los més explicatius i elaboratius.

Fins i tot de vegades, va passar que la nostra OP va escriure històries d’usuaris que tenien 21 o més punts de la història i, per tant, Business Analyst va haver de dedicar més temps i esforços a descompondre-les i prioritzar-les amb el propietari del producte.

Us podeu imaginar què passaria si no hi ha cap analista empresarial i el vostre propietari de producte hagi creat una història d'usuari com ara 'Com a client, vull fer totes les operacions bancàries del meu compte', amb criteris d'acceptació com:

  1. El client hauria de poder iniciar la sessió.
  2. El client hauria de poder fer transaccions al meu compte.
  3. El client hauria de poder descarregar les meves declaracions històriques, etc.

Ara, al meu entendre, aquesta història de l'usuari contindria encara més de 34 punts de la història, per tant, és necessari desglossar-la encara més. Les coses empitjorarien per a l'equip tècnic si no es proporcionen els diagrames de flux i les pantalles d'interfície d'usuari adequats.

Això conduiria a un sprint fallit i, al seu torn, a un projecte fallit. Llevat que el propietari del producte sigui un analista empresarial format / practicat, cal que en tingueu un a l’equip.

Per què s’adapta millor un control de qualitat a aquesta feina?

QA és una persona que prova la solució proposada per a un problema / requisit. Per tant, els analistes de negocis, les parts interessades i els propietaris de productes tenen moltes ganes de conèixer els comentaris d’un control de qualitat. La participació d’un BA en les proves és poc més que la que està desenvolupant.

Un analista de negocis treballa estretament amb un control de qualitat en la revisió de la cobertura de casos de prova que proporciona una visió de fluxos ocults o requisits / efectes. Així, aquest tipus d’intercanvi de coneixement (per part de BA) els fa entendre completament la funcionalitat del producte, les regles de negoci, les expectatives dels clients, els fluxos, les dependències i tot.

El control de qualitat sempre fa proves des del punt de vista del client final que estaria fent servir el producte, de manera que les possibilitats d’ajudar-lo al client per obtenir millores, les millores del producte són més grans (si es compara amb un desenvolupador). Els desenvolupadors desenvolupen el producte per a la història de l'usuari i el conjunt de criteris d'acceptació, però no sempre pensen en com utilitzaria el producte un client .

En desenvolupament, la implementació d’un producte, el flux i les regles estan ben definides, però les proves es basen completament en el pensament lògic i la capacitat de pensar des del punt de vista dels usuaris finals.

QA pot començar a incorporar-se al paper d’analistes empresarials a SCRUM a causa de la gran quantitat d’oportunitats que es presenten en el dia a dia.

Lectura recomanada => Desplaçament professional d'un provador a BA

Per a un control de qualitat és molt fàcil participar en rols com:

  • Estudieu els requisits molt a fons i assenyaleu les llacunes de les reunions de revisió / sessions de pluja d’idees, etc. Intenteu trobar millors solucions i discutiu-les amb l’equip i el BA.
  • Estigueu atent a les trucades amb el propietari del producte, feu preguntes i compartiu les vostres conclusions. Això augmentarà la confiança del propietari del producte que mostri el seu interès pel producte.
  • Comparteix-te entre el BA i l’equip de desenvolupament, hauries de ser el punt de contacte dels desenvolupadors en cas de dubtes o aclariments.
  • Configureu el procés de proves i seguiu innovant-lo, canviant-lo per ajudar a obtenir sprints amb èxit.
  • En el cas de productes amb interfícies d’usuari elegants, busqueu noves tendències i suggeriu aquestes millores.
  • Comprendre el producte completament dins i fora.
  • Creeu un fort coneixement dels vostres grups d'interès, de les seves expectatives i compartiu la vostra experiència amb ells.

Això també implica que per accedir al paper de BA cal millorar les seves habilitats. Al mercat es troben diversos cursos que inclouen tant el nivell bàsic com el nivell avançat.

Sou un BA / QA? Hem assenyalat amb tota raó el vostre paper? O creieu que ens hem perdut? alguna cosa que realitzeu de manera única? Estarem encantats de saber-vos. No dubteu a compartir-los amb nosaltres a la secció de comentaris de sota !!

=> Visiteu aquí per veure la sèrie Business Analyst per a tothom.

Lectura recomanada

^