segunda-feira, 11 de outubro de 2010

Potencializando Projetos Scrum

Oi pessoal,

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

Nenhum comentário: