Menu

Ruolo degli analisti aziendali in SCRUM e perché un QA è il migliore per questo ruolo?

  • Principale
  • Test Agili
  • Ruolo degli analisti aziendali in SCRUM e perché un QA è il migliore per questo ruolo?

role business analysts scrum

come avviare un progetto java in eclipse

Prova Il Nostro Strumento Per Eliminare I Problemi

Ruolo di spicco degli analisti aziendali in SCRUM:

Un analista aziendale che viene brevemente indicato come BA svolge un ruolo molto drastico e importante in MISCHIA .

Questa persona è il collegamento tra il proprietario del prodotto / cliente e il team tecnico IT. Sebbene ci siamo imbattuti in diversi tutorial sul nostro sito Web su BA, questo tutorial sarà in qualche modo unico e ti spiegherà l'importanza di BA in SCRUM.

Esploriamo !!

=> Controlla TUTTI i tutorial per analisti aziendali qui.

Ruolo degli analisti aziendali in SCRUM e perché un QA è il migliore per questo ruolo_

Cosa imparerai:

Responsabilità di un BA

Esistono diversi ruoli degli analisti aziendali in Scrum e ci sono alcune responsabilità a cui dovrebbe aderire un BA.

Di seguito sono menzionati pochi selettivi tra loro.

  • Governare il backlog del prodotto in base alla priorità fornita dal proprietario del prodotto.
  • Analizzare le esigenze del cliente e trovare le soluzioni per affrontarle.
  • Creazione dei requisiti sotto forma di storie utente con criteri di accettazione appropriati.
  • Se nel caso in cui le storie utente siano già state create dal proprietario del prodotto (con criteri di accettazione), esaminarle per assicurarsi che ogni regola aziendale sia coperta e che i criteri di accettazione soddisfino la funzionalità della storia utente.
  • Collaborare con il proprietario del prodotto e le parti interessate per comprendere l'ambito, suggerire miglioramenti ai requisiti, ecc.
  • Preparazione di documenti come wireframe, flusso di progettazione, interfaccia utente, ecc., Come e quando richiesto.

Oltre a questo, a Analista di affari è un partecipante importante alle sessioni di brainstorming quando il team si incontra per discutere il backlog dello sprint imminente. Il BA guida il team, lo aiuta a comprendere i requisiti e, a volte, deve persino approvare l'implementazione.

Lavora anche a stretto contatto con i QA analizzando la copertura dei test, convertendo casi d'uso del mondo reale in casi di test, fornendo informazioni per testare funzionalità complesse, ecc. Il BA partecipa anche alla riunione di pianificazione per aiutare il team nelle stime aiutandoli a comprendere il flusso, la complessità e la dipendenza.

BA deve sempre imparare a conoscere le nuove tendenze in atto nel mercato, continuare a innovare e rimanere aggiornato sull'area di business per la quale il prodotto è stato realizzato.

BA

Analista aziendale come Product Owner

A seconda del cliente e dell'azienda, accade che alcune aziende abbiano il Business Analyst come product owner. In questi casi, la BA è il punto di contatto per tutte le domande. Il BA diventa quindi il mediatore tra il team e le parti interessate.

Il BA deve comprendere i requisiti degli Stakeholder, il loro pensiero su come portare avanti il ​​business e cosa (e come) l'azienda dovrebbe crescere. Quindi, in base ai requisiti degli stakeholder, il BA deve creare i documenti, le user story, dare la priorità alle storie, aiutare il team a comprenderle, rispondere alle loro domande sullo stesso, ecc.

La cosa più importante da notare qui è che questo è consigliabile quando il BA è fisicamente disponibile e non è geolocalizzato su un fuso orario diverso in modo da evitare il 'gap di comunicazione'.

Se il BA come nel proprietario del prodotto è geolocalizzato su un fuso orario diverso, non è possibile avvicinarlo ogni volta e l'unico modo per comunicare è tramite e-mail o chat o chiamate, quindi ciò potrebbe comportare mancanza, lacuna e persino a volte problemi di comunicazione.

Secondo la mia esperienza, questo dovrebbe essere seguito quando il BA è seduto nel tuo ufficio, accanto al tuo team in modo che il tuo lavoro non ostacoli e (s) sia facilmente accessibile. Dal punto di vista di un BA, possiedono il prodotto per conto degli stakeholder / clienti, prendono decisioni appropriate e hanno anche bisogno di apprendere nuove abilità che possono includere l'apprendimento di alcuni aspetti tecnici dello sviluppo.

Avere un analista aziendale come Product Owner è un ulteriore vantaggio perché l'analista aziendale comprende molto bene il prodotto e si possono anche negoziare la priorità e l'ambito delle attività.

BA-PO

Analista aziendale come membro del team

L'altra opzione è avere l'Analista aziendale come membro del team perché il Product Owner non sarà sempre disponibile. Quando l'analista aziendale è un membro del team, aiuta i colleghi nella cura degli arretrati.

Avere un analista aziendale come membro del team è più vantaggioso perché il team tecnico trova facile e comodo comunicare con il BA per chiarimenti o discussioni. Il BA lavora anche a stretto contatto con il team QA per i test, ad esempio per analizzare la copertura, i casi d'uso coperti, eventuali requisiti nascosti, affidabilità o effetti.

A volte i criteri di accettazione scritti dal proprietario del prodotto possono essere vaghi e non chiari, quindi come membro del team, diventa responsabilità del BA scrivere criteri di accettazione elaborati e ben spiegati. Se il team ha bisogno di ulteriori informazioni, il BA crea anche documenti wireframe, documenti di flusso, ecc. Per aiutare il team a comprendere i requisiti.

Nei progetti su larga scala in cui i moduli sono distribuiti tra i team, avere un BA per più di un team è anche un ulteriore vantaggio. Poiché la BA è la stessa per tutti i team, può pensare all'interoperabilità dei moduli, a come le nuove funzionalità o gli aggiornamenti influenzeranno gli altri moduli, ecc.

Quindi questo aiuterebbe molto i team tecnici a considerare tali aspetti poiché non sempre le storie degli utenti oi criteri di accettazione lo menzionano.

Membro del BA_Team

Importanza e ruolo degli analisti aziendali nel team SCRUM

Il ruolo degli analisti aziendali in SCRUM è molto importante per il successo di un progetto. Il loro coinvolgimento parte dalla comprensione delle esigenze del cliente fino alla Sprint Demo. Sono il primo punto di contatto per il team tecnico per chiarimenti. Sono ancora più importanti nelle fasi iniziali di un nuovo progetto e dei progetti di grandi dimensioni.

Il Product Owner non sarà sempre un bravo scrittore, a volte provengono da un background tecnico e quindi diventa responsabilità del Business Analyst scrivere le storie, l'accettazione, i wireframe, ecc.

Nel mio progetto, il nostro PO non era così buono con la documentazione e anche le storie degli utenti scritte non erano mai più di 2-3 righe mentre i criteri di accettazione erano solo 1 riga. Era l'analista aziendale che era solito modificarli, renderli più esplicativi ed elaborativi.

Anche a volte, è successo che il nostro PO ha scritto storie di utenti con 21 o più story point, e quindi l'analista aziendale ha dovuto dedicare tempo e sforzi extra per scomporli e dare loro priorità con il Product Owner.

Puoi immaginare cosa succederebbe se non ci fosse un analista aziendale e il tuo Product Owner avesse creato una user story del tipo 'Come cliente, voglio eseguire tutte le operazioni bancarie per il mio account', con criteri di accettazione come:

  1. Il cliente dovrebbe essere in grado di accedere.
  2. Il cliente dovrebbe essere in grado di effettuare transazioni nel mio account.
  3. Il cliente dovrebbe essere in grado di scaricare le mie dichiarazioni storiche ecc.

Ora, secondo me, questa user story conterrebbe anche più di 34 story point, quindi è necessario scomporla ulteriormente. Le cose peggiorerebbero per il team tecnico se non fossero forniti i diagrammi di flusso e le schermate dell'interfaccia utente (da creare) corretti.

Ciò porterebbe a uno sprint fallito e, a sua volta, a un progetto fallito. A meno che il Product Owner non sia un Business Analyst addestrato / esperto, è necessario averne uno nel team.

Perché un QA è la soluzione migliore per questo lavoro?

Il QA è una persona che verifica la soluzione proposta per un problema / requisito testandola. Pertanto, l'analista aziendale / gli stakeholder / i proprietari del prodotto sono molto ansiosi di conoscere il feedback di un QA. Il coinvolgimento di un BA nei test è poco più di quello che è in fase di sviluppo.

Un analista aziendale lavora a stretto contatto con un addetto al controllo qualità per esaminare la copertura del caso di test che fornisce una panoramica dei flussi o dei requisiti / effetti nascosti. Quindi questo tipo di condivisione della conoscenza (da parte del BA) fa capire loro la funzionalità del prodotto, le regole aziendali, le aspettative del cliente, i flussi, le dipendenze e tutto completamente.

Il QA verifica sempre dal punto di vista del cliente finale che utilizzerebbe il prodotto, quindi le possibilità di aiutare il cliente per miglioramenti, miglioramenti nel prodotto sono maggiori (rispetto a uno sviluppatore). Gli sviluppatori sviluppano il prodotto per una data user story e l'insieme di criteri di accettazione, ma non sempre pensano a come un cliente utilizzerebbe il prodotto .

In fase di sviluppo, l'implementazione di un prodotto, il flusso e le regole sono ben definiti ma i test si basano completamente sul pensiero logico e sulla capacità di pensare dal punto di vista degli utenti finali.

Il controllo qualità può iniziare a entrare nel ruolo di analisti aziendali in SCRUM a causa delle molte opportunità che si presentano nel lavoro quotidiano.

Lettura consigliata => Passaggio di carriera da Tester a BA

È molto facile per un QA entrare in ruoli come:

  • Studia i requisiti in modo molto approfondito e sottolinea le lacune nelle riunioni di revisione / sessioni di brainstorming, ecc. Prova a pensare a soluzioni migliori e discuti lo stesso con il team e il BA.
  • Sii attento nelle chiamate con il Product Owner, fai domande e condividi le tue scoperte. Ciò aumenterà la fiducia del Product Owner che mostra il tuo interesse per il prodotto.
  • Posizionati tra il BA e il team di sviluppo, dovresti essere il punto di contatto per gli sviluppatori in caso di chiarimenti o dubbi.
  • Imposta il processo di test e continua a innovarlo, modificandolo per aiutare a fornire sprint di successo.
  • Nel caso di prodotti con interfacce utente fantasiose, cerca le nuove tendenze e suggerisci tali miglioramenti.
  • Comprendere il prodotto completamente dentro e fuori.
  • Costruisci una solida conoscenza dei tuoi stakeholder, delle loro aspettative e condividi la tua esperienza con loro.

Ciò implica anche che per entrare nel ruolo di BA è necessario migliorare le proprie capacità. Sul mercato si trovano diversi corsi che includono sia il livello base che il livello avanzato.

Sei un BA / QA? Abbiamo giustamente indicato tutto sul tuo ruolo? Oppure pensi che ci siamo persi qualcosa che esegui in modo unico? Saremo lieti di ricevere tue notizie. Sentiti libero di condividerli con noi nella sezione commenti qui sotto !!

=> Visita qui per vedere la serie di analisti aziendali per tutti.

Lettura consigliata

^