Considerando a prática ágil, podemos dizer o que PO agrega as atividades que tradicionalmente chamamos "análise de requisitos " ? me parece mais adequado que o PO de uma visão de alto nível, afinal a especificação de requisitos pode ser uma atividade técnica demorada. Porém assim o time não ficaria um pouco "perdido" na execução? mesmo considerando o contexto de uma janela pequena de produção de curta duração (sprint de 2 semanas) e as premissas de evolução contínua do método ágil.
Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta
resposta
Análise de requisitos?
solução!
Olá Reginaldo,
A ideia do P.O. é que esta pessoa seja aquela que conhece do negócio e do produto. Então é responsabilidade dele gerenciar todo o Product Backlog de histórias, estar em constante contato com o cliente para entender as suas necessidades e tirar dúvidas dos desenvolvedores a respeito das regras de negócio que devem ser implementadas.
E uma coisa muito interessante no Scrum é que o P.O. faz parte do time, junto dos desenvolvedores e do Scrum Master. Então ele precisa estar próximo e disponível para as outras pessoas, como membro do time. E um dos trabalhos do P.O. no time é que no planning ele explique cada uma das histórias para os desenvolvedores de forma que eles já tenham ideia do que será feito na sprint. E durante a fase de desenvolvimento, se o programador ficar perdido com algum aspecto do produto, ele pode ir conversar diretamente com o P.O. para tirar esta dúvida. Se o P.O. souber responder a dúvida então ela é rapidamente resolvida. Caso contrário. por justamente ter o conhecimento do negócio, o P.O. saberá com qual cliente/usuário o programador pode conversar para tirar a sua dúvida.