Neste post eu vou mostrar como podemos melhorar a produtividade de uma equipe ágil de desenvolvimento de software que está utilizando Scrum.
O primeiro passo é o Product Owner saber os requisitos em alto nível do seu projeto, estes requisitos vão ser apresentados a equipe de execução do projeto como sendo uma visão do produto.
O Scrum Master e o Product Owner preparam os requisitos para a primeira Sprint, para que os requisitos que vão ser apresentados a equipe de desenvolvimento estejam possíveis de ser implementados.
Enquanto a equipe de desenvolvimento do projeto está executando a Sprint que foi preparada pelo Product Owner e o Scrum Master, o Product Owner e o Scrum Master já estão preparando os requisitos da próxima Sprint.
Isso faz com que o nosso Backlog fique sendo refinado por Sprint e não de uma única vez antes do inicio do projeto. Também faz com que o Backlog não fique entrando no Planejamento da Sprint como um requisitos muito grandes (Épicos ou Temas), o que vai permitir um entendimento melhor da equipe de execução do projeto e também vai permitir um Planejamento de Sprint mais rápida.
Uma boa pratica é pegar os nossos requisitos, que estão em forma de Histórias, e levar para a equipe de desenvolvimento algum material de apoio ao entendimento do requisito. Pode ser até mesmo uma tela, rascunhada a mão ou desenhada por alguma ferramenta. Mas devemos lembrar, que este recurso é apenas para facilitar o entendimento da equipe de execução do projeto, onde a equipe vai idealizar a melhor forma de atender a demanda.
Uma História: Como um consumidor de livros, desejo realizar o meu cadastro, para que eu posso realizar compras pela internet.
Pode ter uma solução como o desenho:
A solução proposta possui algumas funcionalidades, como a validar e-mail, validar CPF, validar Captcha, validar “concordo”, mandar e-mail de ativação da conta, validar senha, etc.
Estas funcionalidades são chamadas de “conversas” de entendimento da História.
Podemos pegar todas as Histórias e priorizar com MoScoW, mas a priorização por História nem sempre permite uma boa negociação com o Product Owner, principalmente quando o nosso Product Owner ainda não possui maturidade em projetos Scrum.
Porem, se pegarmos uma Histórias que possui várias funcionalidades e realizarmos uma priorização por MoSCoW por funcionalidades a negociação com o Product Owner fica mais fácil, pois o História está sendo executada, porem não vai ter 100% das funcionalidades, apenas as que foram definidas como "Must".
O próximo passo é executar apenas funcionalidades “Must”.
Espero que tenham gostado do post.
Um abraço a todos,
Abu
Postagens
Nenhum comentário:
Postar um comentário