Menu

Função dos analistas de negócios no SCRUM e por que um controle de qualidade é melhor para essa função?

  • Principal
  • Teste Ágil
  • Função dos analistas de negócios no SCRUM e por que um controle de qualidade é melhor para essa função?

role business analysts scrum

criando um makefile c ++

Experimente Nosso Instrumento Para Eliminar Problemas

Papel proeminente dos analistas de negócios no SCRUM:

Um analista de negócios que é brevemente denominado BA desempenha um papel muito drástico e importante na SCRUM .

Essa pessoa é o elo entre o proprietário do produto / cliente e a equipe técnica de TI. Embora tenhamos encontrado vários tutoriais em nosso website sobre BA, este tutorial será de alguma forma único e explicará a você a importância do BA no SCRUM.

Vamos explorar!!

=> Verifique TODOS os tutoriais de analistas de negócios aqui.

Função dos analistas de negócios no SCRUM e por que um controle de qualidade é melhor para essa função_

O que você aprenderá:

Responsabilidades de um BA

Existem várias funções de analistas de negócios no Scrum e certas responsabilidades que um BA deve cumprir.

Poucos seletivos entre eles são mencionados abaixo.

  • Preparar o backlog do produto com base na priorização fornecida pelo product owner.
  • Analisar as necessidades do cliente e encontrar as soluções para atendê-las.
  • Criar os requisitos na forma de histórias de usuários com critérios de aceitação apropriados.
  • Caso as histórias de usuário já tenham sido criadas pelo proprietário do produto (com critérios de aceitação), revise-as para ter certeza de que todas as regras de negócios estão cobertas e os critérios de aceitação atendem à funcionalidade da história de usuário.
  • Trabalhar com o product owner e as partes interessadas para entender o escopo, sugerir melhorias para os requisitos, etc.
  • Preparar documentos como wireframes, fluxo de design, UI, etc., como e quando necessário.

Além disso, um Analista de negócios é um participante importante nas sessões de brainstorming, quando a equipe se reúne para discutir o backlog do próximo sprint. O BA orienta a equipe, ajuda-os a entender os requisitos e às vezes tem que aprovar a implementação.

Ele também trabalha em estreita colaboração com os QAs, analisando a cobertura de teste, convertendo casos de uso do mundo real em casos de teste, fornecendo informações para testar funcionalidades complexas, etc. O BA também participa da reunião de planejamento para ajudar a equipe nas estimativas, ajudando-os a compreender o fluxo, a complexidade e a dependência.

A BA tem que estar sempre conhecendo as novas tendências que estão acontecendo no mercado, inovar e se manter atualizada sobre a área de negócio para a qual o produto foi feito.

BA

Analista de negócios como proprietário do produto

Dependendo do cliente e da empresa, acontece que algumas empresas têm o Analista de Negócios como product owner. Nestes casos, o BA é o ponto de contato para todas as consultas. O BA então se torna o mediador entre a equipe e as partes interessadas.

O BA deve entender os requisitos dos Stakeholders, seu pensamento sobre como levar o negócio adiante e o que (e como) o negócio deve crescer. Então, com base nos requisitos dos Stakeholders, o BA deve criar os documentos, histórias de usuários, priorizar as histórias, ajudar a equipe a entendê-los, responder suas dúvidas sobre os mesmos, etc.

A coisa mais importante a notar aqui é que isso é aconselhável quando o BA está fisicamente disponível e não é geolocalização para um fuso horário diferente, a fim de evitar a 'lacuna na comunicação'.

Se o BA, como no product owner, for geolocalização para um fuso horário diferente, então não será possível abordá-lo todas as vezes e a única forma de se comunicar é por e-mails ou chats ou ligações, podendo resultar em falta, lacuna e até falha de comunicação às vezes.

De acordo com minha experiência, isso deve ser seguido quando o BA está sentado em seu escritório, ao lado de sua equipe para que seu trabalho não atrapalhe e ele seja facilmente acessível. Do ponto de vista de um BA, eles possuem o produto em nome das partes interessadas / clientes, tomam as decisões adequadas e até mesmo precisam aprender novas habilidades que podem incluir aprender alguns aspectos técnicos do desenvolvimento.

Ter um Analista de Negócios como Dono do Produto é uma vantagem adicional porque o Analista de Negócios entende o produto muito bem, e a priorização e o escopo das tarefas também podem ser negociados.

BA-PO

Analista de negócios como membro da equipe

A outra opção é ter o Analista de Negócios como membro da equipe, pois o Dono do Produto não estará disponível o tempo todo. Quando o analista de negócios é um membro da equipe, ele ajuda os colegas na preparação do backlog.

Ter um Analista de Negócios como membro da equipe é mais vantajoso porque a equipe técnica acha fácil e confortável se comunicar com o BA para esclarecimentos ou discussões. O BA também trabalha em estreita colaboração com a equipe de QA para testes, ou seja, analisando a cobertura, os casos de uso cobertos, quaisquer requisitos ocultos ou confiabilidade ou efeitos.

Às vezes, os critérios de aceitação escritos pelo Product owner podem ser vagos e não claros; então, como um membro da equipe, torna-se responsabilidade do BA escrever critérios de aceitação elaborados e bem explicados. Se a equipe precisar de mais informações, o BA também cria documentos de wireframe, documentos de fluxo, etc. para ajudar a equipe a entender os requisitos.

Em projetos de grande escala, onde os módulos são distribuídos entre as equipes, ter um BA para mais de uma equipe também é uma vantagem. Uma vez que o BA é o mesmo entre as equipes, ele pode pensar sobre a interoperabilidade dos módulos, como os novos recursos ou atualizações afetarão os outros módulos, etc.

Assim, isso ajudaria muito as equipes técnicas a considerarem tais aspectos, pois nem sempre as histórias de usuários ou os critérios de aceitação os mencionam.

BA_ membro da equipe

Importância e papel dos analistas de negócios na equipe SCRUM

O papel dos Analistas de Negócios no SCRUM é muito importante para o sucesso de um projeto. Seu envolvimento começa desde a compreensão da necessidade do cliente para a Demonstração da Sprint. Eles são o primeiro ponto de contato da equipe técnica para esclarecimentos. São ainda mais importantes nas fases iniciais de um novo projeto e nos projetos de grande escala.

O Product Owner nem sempre será um bom redator, às vezes eles vêm de uma formação técnica e, portanto, torna-se responsabilidade do Analista de Negócios escrever as histórias, aceitação, wireframes, etc.

Em meu projeto, nosso PO não era tão bom com documentação e mesmo as histórias de usuário escritas nunca foram mais do que 2-3 linhas, enquanto os critérios de aceitação foram apenas 1 linha. Era o Analista de Negócios que costumava modificá-los, torná-los mais explicativos e elaborativos.

Mesmo às vezes, aconteceu que nosso PO escreveu histórias de usuários que tinham 21 ou mais pontos de história e, portanto, o analista de negócios teve que gastar tempo e esforços extras para dividi-los e priorizá-los com o Dono do Produto.

Você pode imaginar o que aconteceria se não houvesse um Analista de Negócios e seu Product Owner tivesse criado uma história de usuário como 'Como cliente, quero realizar todas as operações bancárias para minha conta', com critérios de aceitação como:

  1. O cliente deve conseguir fazer login.
  2. O cliente deve ser capaz de fazer transações em minha conta.
  3. O cliente deve ser capaz de baixar minhas declarações históricas, etc.

Agora, na minha opinião, essa história de usuário teria ainda mais de 34 pontos de história, portanto, é necessário dividi-la ainda mais. As coisas piorariam para a equipe técnica se os fluxogramas e telas de IU adequados (a serem criados) não fossem fornecidos.

Isso levaria a um sprint com falha e, por sua vez, a um projeto com falha. A menos que o Product Owner seja um Analista de Negócios treinado / experiente, é necessário ter um na equipe.

Por que um controle de qualidade é mais adequado para este trabalho?

GQ é a pessoa que verifica a solução proposta para um problema / requisito testando-a. Conseqüentemente, o analista de negócios / partes interessadas / proprietários do produto estão muito ansiosos para saber sobre o feedback de um controle de qualidade. O envolvimento de um BA em testes é pouco mais do que o que está em desenvolvimento.

Um analista de negócios trabalha em estreita colaboração com um QA na revisão da cobertura do caso de teste, que fornece uma visão dos fluxos ocultos ou requisitos / efeitos. Assim, esse tipo de compartilhamento de conhecimento (pelo BA) faz com que eles entendam a funcionalidade do produto, as regras do negócio, as expectativas do cliente, os fluxos, dependências e tudo mais completamente.

QA sempre testa do ponto de vista do cliente final que estaria usando o produto, daí as chances de ajudar o cliente para melhorias, melhorias no produto são maiores (quando comparado a um desenvolvedor). Os desenvolvedores desenvolvem o produto para a história de usuário fornecida e o conjunto de critérios de aceitação, mas nem sempre pensam sobre como um cliente usaria o produto .

No desenvolvimento, a implementação de um produto, o fluxo e as regras são bem definidos, mas o teste é totalmente baseado no pensamento lógico e na capacidade de pensar do ponto de vista dos usuários finais.

O QA pode começar a assumir a função de Analistas de Negócios no SCRUM por causa das muitas oportunidades que são apresentadas no dia a dia de trabalho.

Leitura recomendada => Mudança de carreira de testador para bacharelado

É muito fácil para um QA assumir funções como:

  • Estude os requisitos muito profundamente e aponte as lacunas nas reuniões de revisão / sessões de brainstorming, etc. Tente pensar em soluções melhores e discuta as mesmas com a equipe e o BA.
  • Fique atento às ligações com o Product Owner, faça perguntas e compartilhe suas descobertas. Isso aumentará a confiança do Dono do Produto em mostrar seu interesse no produto.
  • Coloque-se entre o BA e a equipe de desenvolvimento, você deve ser o ponto de contato dos desenvolvedores em caso de esclarecimentos ou dúvidas.
  • Configure o processo de teste e continue inovando, mudando-o para ajudar na entrega de sprints de sucesso.
  • No caso de produtos com interfaces de usuário sofisticadas, procure novas tendências e sugira essas melhorias.
  • Entenda o produto completamente por dentro e por fora.
  • Desenvolva um forte conhecimento de seus stakeholders, suas expectativas e compartilhe sua experiência com eles.

Isso também implica que, para entrar na função de BA, você precisa aprimorar suas habilidades. Diversos cursos que contemplam tanto o nível básico quanto o avançado são encontrados no mercado.

Você é um BA / QA? Indicamos corretamente tudo sobre a sua função? Ou você acha que perdemos algo que você executa de forma única? Ficaríamos contentes de ouvir de você. Sinta-se à vontade para compartilhá-los conosco na seção de comentários abaixo !!

=> Visite aqui para ver a série de analistas de negócios para todos.

Leitura recomendada

^