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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYCzZ6qIRHrpv_GLECfGHSsyPnmhfgPzEN7Xt768kkST0WoZr3pOIpTSlboD6WkACcD-Lk6Y8nW3Bo_12XklzWYHygyD2K7DnDgBePLbNJPrwO47TBhmpvJAZ0BLL4VJ8usiYL_XAtd-4/s400/VisaoProduto_Requisitos.png)
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgowfzlI_vCDSfACP_sN5ykfIyCd2IL7q5ffjFvqdZ0mATKLPlTnIpxgVQgYbQ3nZl7yNtZiJZfcspyLRHRQF_4rgYxqLnNh717qeICN4XtFYkZYPYmSVaa0K3D2yvzAGoR2txVsJvNbRY/s400/Sucesso_Scrum_Requisitos.png)
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.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuNDJpIuYLhpaNmbhI__bYqu4vbBH_09qbffSVALgs5d9D9r90g03HhHvhw5mSatDUyJbM0_lCGTBDaOSqAq4PgrUUGfzipvn6NNx3InbT0QPinuTiZS_lbpe6XIEdCrph-nxjQ4mkcYA/s400/RefinamentoRequisitos.png)
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:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpKCiBwZa0xiHo3MCyPi_cSSh30WUcJslTEq22BweUmbaaGpejIdSTjvzVeOW73CuWOstZKs1ADdnbcmReA3Lu44xKMrHK15zX65bxC0pLjCRHEFMfNhyH-r-9QTwKAkEAPrbqGuB3s4Q/s400/Usuarios.png)
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".
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuUtqew_ay53rNyBqE7CHlccCd-hh7Xn3ilnVb3mAtcG4TCspe2TDWFdgSSj4EnE12W2NEZW00fLwVdx8I_jjibNSFLwmndJVQgw5zLcuzD1nHTpsVGmo7D2pSMHWV2AuFG4KN4-IyyVw/s400/MoSCoW_Features.png)
O próximo passo é executar apenas funcionalidades “Must”.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsQJZYMNbuh8bXi0h5oVOrcUozUBVRg2xPVr_M7e5hNYo4nUwDjgbXiIw0WSqGTsjocoAOankqL8d9ARVlzbHkznH8PBtBWnfOlrNcgIFuZ3A1OyMwHHMdH1wvFQ0MNIRXPBTJ-vGyhYo/s400/story_map_07.png)
Espero que tenham gostado do post.
Um abraço a todos,
Abu
Nenhum comentário:
Postar um comentário