Os métodos ágeis estão ganhando muita força, não só pelas empresas desenvolvedoras de softwares, mas também por orgãos reconhecidos e respeitados. Um dos exemplos que podemos citar é o lançamento da certificação PMI-ACP ( PMI Agile Certified Practioner ), concedida pelo Instituto de Gerenciamento de Projeto ( PMI ). Essa certificação é indicada para àqueles que utilizam práticas ágeis em seus projetos. Como dito em seu site, essa certificação foi criada para reconhecer e validar o conhecimento dessa nova maneira de desenvolver projetos. Além do PMI, o IIBA, Instituto Internacional de Análise de Negócio, apresentou uma parceria com a aliança ágil com a finalidade de publicar um documento sobre o papel do Analista de negócio no desenvolvimento ágil. E é sobre essa parceira que iremos tratar ao longo deste post.
Em novembro de 2011, o IIBA liberou a público uma versão do que será a extensão ágil do guia BABoK. O BABoK, para quem não o conhece, é um guia de boas práticas e técnicas que são sugeridas aos analistas de negócio. Atualmente ele se encontra na versão 2.0 e há rumores que a versão 3.0 sairá ainda este ano. Essa extensão foi criada em parceria com a Aliança ágil e busca adequar os processos de trabalho aos métodos ágeis emergentes. Vamos começar falando sobre o que faz um Analista de Negócio e depois falaremos sobre seu papel no Scrum.
O analista de negócio possui papel fundamental para o sucesso de um projeto de software. Seu objetivo é entender como o cliente trabalha e descobrir em quais pontos a TI deverá apoiar. Ele é responsável por compreender as necessidades dos negócios e ajudar a mapear soluções que atendam as expectativas dos stakeholders. Sua busca é pelo alinhamento estratégico que a área de TI deve ter. Para um analista de negócio, é importante conhecer os objetivos que a empresa quer alcançar, descrever um plano que envolva a TI de como esse objetivo vai ser atingido e monitorar e avaliar se a meta está sendo atingida.
No contexto do Scrum, não existe um papel pré-definido para o Analista de negócio. No entanto, como já vimos em outros posts, Scrum é um framework e não uma norma. A recomendação da extensão ágil do BABoK é que o processo de análise de negócio ocorra em paralelo com o processo de desenvolvimento do produto. Na medida que o produto vai sendo feito, o Analista deve trabalhar com a análise de requisitos, o alinhamento da solução com o problema e a validação do que foi entregue para gerar novos histórias a serem desenvolvidas, como na figura abaixo, retirada do documento em questão. Apesar do guia não indicar nenhum papel para esse Analista, pela minha experiência, indicaria uma posição em que ele pudesse apoiar o Product Owner ( PO ) na descrição e criação dos itens do Product Backlog. No caso mais extremo, o Analista poderia entrar até mesmo como o próprio PO do projeto.
Espero que ao final deste post muitas dúvidas tenham sido esclarecidas e que você tenha aproveitado bastante a leitura. Se por acaso ainda tiver dúvidas ou algum conceito não ficou muito claro, deixe seu comentário abaixo e poderemos discutir mais sobre o assunto! Até a próxima!
Olá, pessoal!
Gostei muito da discussão. Gostaria de propor uma opção, acredito que está alinhada ao texto:
O Scrumguide propõe um refinamento contínudo do backlog ao longo das sprints (algo que chamamos de grooming). Normalmente, na empresa que trablaho o analista de negócio atua em conjunto com o PO durante as sessões de grooming.
O que vocês acham?
abraço
Oi Edson,
achamos sensacional. O Scrum guide destaca a necessidade do grooming e a responsabilidade do PO. Um PO que disponha de recursos para tal, deve sempre usar outros stakeholders para ajudar no refinamento do Backlog. No caso que você cita, de sua empresa, a união desses dois perfis só pode trazer um produto final mais alinhado com a demanda do negócio. Muito bom! Esse é um ótimo caminho.
Obrigado pela colaboração e um abraço.
Olá, bom dia.
Está sendo implantado o scrum na empresa que trabalho e estamos enfrentando muitas dúvidas com relação ao papel do PO x AN também. Pior ainda pois criaram o papel de BP (Business Partner) para atender a área usuária e quem está fazendo este papel é o analista técnico, só que ele não faz a especificação funcional deixando esta função para o Analista de negócios. Ele também está atuando como PO; portanto, eu como AN estou tendo muitas dificuldades para trabalhar neste modelo pois não tenho atuado na análise das necessidades junto a área usuária e no entanto tenho que documentar a solução proposta pelo analista técnico mesmo não concordando como a solução, ou seja, uma confusão danada.
Gostaria de dicas de como dividir este papel de PO x AN porque os papeis estão se misturando e não está sendo produtivo.
Grata
Tereza
Oi Tereza,
Como o artigo diz, as tarefas discutidas são de uma forma geral do PO. Isso não significa que têm que serem feitas por somente uma pessoa, visto que o PO pode ter uma equipe para auxiliá-lo.
Não sei se entendi direito, mas me parece que o PO é o BP, e é auxiliado por você, que é AN. Me pareceu que o problema é de divisão de tarefas, certo? Se é esse o caso, acho que algumas questões podem ser colocadas entre vocês, para discussão e solução.
O problema é o BP ser o PO? Ou o problema é o background do PO ser técnico?
Deveria o BP ser um técnico? Já vi muito DEV migrar para a análise, com sucesso. Mas já vi muito insucesso também.
Deveria o PO ser um técnico ou um AN, visto que a ideia é que o PO diga o que é necessário e não como isso deve ser feito?
O problema está na divisão de tarefas ou na relação de subordinação?
Recomendaria que vocês discutissem essas questões cara a cara, para evitar mal entendidos. Acredito que a chance de vocês conseguirem uma divisão de tarefas que seja a melhor para o produto e para vocês é grande, claro, se propuserem-se a buscar o melhor, deixando egos de lado.
Lembre-se que transparência e coragem são atributos fundamentais no Scrum.
Boa sorte e obrigado por visitar o nosso blog. Gostamos muito dessa troca.
Felipe, boa tarde! Parece que os papéis de AN e PO ainda causam muita confusão pois qualquer um que consiga conversar com o cliente e 'traduzir" seus anseios para o time já ganho o título de AN. Ou se estiver no "Scrum Mode:ON", ganhará o título de PO.
Como a Ester disse, se trouxe resultados é o que importa, porém as "verdadeiras" responsabilidades não poderão ser cobradas. Um PO não teria condições "de negócio" para orquestrar o que deve ser feito nem um AN orquestrar como o time deve atacar o backlog.
Mesclar esse dois papéis até que funciona mas o único problema e o pleno conhecimento das suas reais responsabilidades.
"No caso mais extremo, o Analista poderia entrar até mesmo como o próprio PO do projeto."
Esse é um tópico bem conceitual que acaba gerando muitas horas de discussão, o que no fim, o que nosso cliente quer é um software rodando, em um curto espaço de tempo e sem erros.
Felipe, um ótimo post e caso discorde de alguma coisa, aceito réplicas! rsrsrs… um abraço!
Olá Alexandre!
Que bom que gostou do post! Fico contente em proporcionar uma boa leitura e um bom debate! rsrs…
Concordo com suas colocações. Acredito que muitas qualidades de um bom AN deverão existir em um bom PO, mas isso não significa que um bom AN será um bom PO e vice-versa. As responsabilidades e as expectativas em cima das pessoas que estão exercendo cada papel são diferentes. Portanto o ideal é mesmo ter a colaboração entre eles. Na prática, nunca vivi a situação em que um AN fosse intitulado de PO do projeto, mas acredito no poder de adaptação das pessoas e acho que, após algumas sprints, seria possível definir se naquele caso específico a substituição funcionará ou não.
Um abraço e não deixe de comentar!
Muito bem abordado o assunto. Porque realmente muitas equipes ficam na dúvida de como tratar perfis como Analista de Negócio, equipe de testes, dentre outros, no Scrum.
Estou com o Alexandre, AN e PO são perfis distintos, o comum é o AN participar da equipe do PO, trabalhando junto com ele no preparo das histórias, mas se no caso do Leonardo a adaptação de AN sendo o PO foi o que trouxe bons resultados, então isso é que importa.
Essa é a vantagem do Scrum: inspecionar em intervalos curtos para permitir adaptar o processo em conformidade.
Leonardo, acredito que o AN e o PO são perfis bem diferentes podendo ser complementares mas não substituíveis.
Em alguns projetos aqui na empresa usamos o Analista de Negócios substituindo o PO ( com sua aprovação ) e obtivemos bons resultados com essa adaptação.