Oi pessoal,
Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.
Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com
Após a correção técnica e ortográfica o material vai ser disponibilizado para download.
Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html
Abraços,
Abu
O ato de estimar o tempo necessário para a conclusão de um projeto sempre tem uma porção de “chute”, nós apenas sabemos o tempo necessário para a realização de uma tarefa quando está tarefa já esta concluída.
Antes de sua conclusão apenas temos uma noção do tempo que vai ser necessário, ou apenas um desejo do que acreditamos ser possível de ser realizado.
Um projeto de um ano, onde existe um erro de uma hora por dia de trabalho, ao término de um ano teremos mais de 200 horas de atraso.
Em desenvolvimento ágil nós realizamos a estimativa de um projeto pela contagem de pontos, onde um ponto é uma forma de comparação de esforço necessário para a realização de um requisito.
Mas nós também temos uma estimativa em horas, que é realizada na quantidade de tarefas existente em uma Sprint.
A estimativa em pontos busca a visão do esforço do projeto e deve ser reestimada varias vezes durante o projeto, para corrigirmos imperfeições iniciais. Já a estimativa da Sprint, utilizando tarefas estimadas em horas tem o objetivo de saber se a quantidade de trabalho identificado é comportada pela equipe.
Contando os Pontos
O cliente solicitou uma data de termino da entrega do projeto, para que ele possa realizar uma analise de riscos com relação a data limite da entrega do projeto e o inicio do período de vendas de material escolar.
A equipe se reúne com o Product Owner para realizar as estimativas necessárias. Os requisitos utilizados são os de tamanho de “Temas”.
Com cada um dos requisitos escritos em papeis e colocados sobre a mesa a equipe busca os de menos esforço de trabalho. Está busca tem o objetivo de escolher um requisito que vai ser utilizado como ponto de referencia, uma ancora em relação aos demais.
A participação do Product Owner é fundamental, pois a cada requisito em tamanho igual a um “Tema” a equipe pode solicitar maiores informações e o Product Owner passa a responder estas informações. Está reunião inclusive é um ótimo momento de anotarmos mais requisitos contidos num “Tema”, para atualização do nosso Product Backlog.
A equipe por consenso identifica o requisito de tamanho menor, este requisito é o de Categoria de Produtos. Para facilitar o processo de contagem de pontos buscamos os requisitos que são um pouco maior que o menor, pois sempre aparecem requisitos menores ao que nos estamos utilizando como base, isto é, ancora.
Por consenso a equipe escolhe o Cadastro de Clientes e este recebe o valor igual a dois pontos. Dois pontos neste momento da técnica de estimativa não tem nenhuma correlação com o tempo necessário para a relação do projeto, apenas representa o tamanho do esforço necessário para a construção deste “Tema”.
Com o requisito de tamanho igual a dois passamos a comparar este requisito com os demais e atribuir aos demais os valores em pontos correspondentes. A escala de pontos utilizado é a de Fibonacci, 1, 1, 2, 3, 5, 8, 13, 21, 34, ?.
O processo de contagem de pontos, nós utilizamos o Planning Poker, baralhos com os pontos de Fibonacci, para que ninguém da equipe influencie o outro. Jogamos as cartas viradas para baixo e todos ao mesmo tempo viraram as cartas para cima, onde podemos realizar a analise dos pontos jogados.
Quando as cartas possuem valores iguais significa que a equipe chegou a um consenso do tamanho do esforço, mas quando as cartas possuem valores diferentes é sinal que a equipe não esta fechada em um consenso. Neste momento entra o Scrum Máster como um facilitador perguntando a cada pessoa da equipe o porquê dos valores de suas cartas, o que cada pessoa está identificando de esforço a mais do que o outro colega de trabalho.
As duvidas, incertezas, requisitos que nos acreditamos ser verdadeiros e contidos no requisito de tamanho igual a “Temas” do requisito que está sendo estimado, nos devemos perguntar ao Product Owner, para que ele valide e deixe claro para a equipe a abrangência do esforço necessário.
Não existindo mais duvidas as cartas são jogadas de novo e a equipe busca o consenso do esforço. O processo pode ser repetido quantas vezes forem necessárias, com o tempo a equipe acha o seu ponto de equilíbrio nas estimativas.
É importante sempre deixarmos como consenso do resultado do processo de Planning Poker as cartas de maior valor, para que todas as pessoas da equipe se sintam a vontade em executar o requisito estimado no tempo que ela acredita ser exeqüível.
Exemplo de Pontos Contados
Tema - Pontos
Cadastro de Clientes - 2
Cadastro de Produtos - 2
Carrinho de Compras - 13
Busca de Produtos - 2
Categoria de Produtos - 1
Histórico de Compras - 5
Rastreamento de uma Compra - 8
Pagamento por Cartão de Credito - 8
Pagamento por Boleto Bancário - 13
Exportação de Dados p/ EPR - 13
Total - 67 pts
Determinando o Tempo do Projeto
O primeiro passo para sabermos o tempo do projeto é a definição do tamanho da nossa Sprint, lembrando que uma Sprint é um tempo de trabalho, que pode ser de uma, duas, três ou quatro semanas, mas uma vez definido o tamanho da Sprint ela não deve ser modificada até o termino do projeto, para não termos que regêramos gráficos e informações do projeto sobre o novo tamanho da Sprint, o que irá gerar um re-trabalho.
A equipe junto com o Product Owner determina que a Sprint vai ser de uma semana. Uma vez sabendo o tamanho da Sprint é perguntada a equipe a quantidade de pontos que a equipe consegue executar em uma Sprint. Este valor está diretamente vinculado ao que tem que ser feito e a quantidade de pessoas que a nossa equipe possui. Também neste valor está incluso o nosso processo de desenvolvimento do software, onde ele deve abranger tudo que for necessário, como testes de software, UML, documentação e o que for definido pela equipe e os interesses do cliente, representado pelo Product Owner.
A equipe definiu a quantidade de 10 pontos por Sprint, agora temos condições de dar uma previsão ao cliente do tempo necessário para o desenvolvimento do sistema, bastando apenas pegar a quantidade de pontos contados e dividir pela quantidade de pontos que a equipe é capaz de executar. A quantidade de pontos que a equipe é capaz de executar por Sprint é a “Velocidade da Equipe”.
O resultado da operação matemática chegou ao valor de: 67 / 10 = 6 com resto de 7. Seis (6) é a quantidade de Sprint’s necessárias para a realização do projeto. Vamos arredondar para sete (7), pois temos o resto da divisão. Sete semanas são iguais a aproximadamente dois meses de trabalho.
Podemos também realizar o calculo da Velocidade da Equipe com as informações coletadas após a execução da primeira Sprint e com este dado calculamos o tempo de execução do projeto.
Product Burndown Chart
Também conhecido como o gráfico de ciclo de vida do projeto, que tem o objetivo de mostrar como está o andamento do projeto inteiro.
Colocamos no Eixo Y os pontos do projeto e colocamos no Eixo X a quantidade de Sprint’s. Passamos uma reta mostrando a meta dos pontos a serem executados pela quantidade de Sprint’s do nosso projeto, respeitando a Velocidade da Equipe.
Uma segunda linha é gerada a cada execução de Sprint, com o objetivo de mostrar se a nossa meta foi alcançada ou não. A cada execução de Sprint a nossa velocidade pode ser recalculada e conseqüentemente o tempo do projeto passa a sofrer alteração.
Este gráfico fica muito bem disponibilizado em uma parede do lado da equipe de desenvolvimento. Quando todas as pessoas envolvidas no projeto, direta ou indiretamente aprenderem a ler este gráfico não existe mais a necessidade de responder aos interessados a pergunta: “Como está indo o projeto de Venda de Livros pela Internet?”, pois a informação está disponibilizada a todos, permitindo uma comunicação direta e rápida. Se o escopo do projeto passa a sofrer alterações o gráfico sofre a necessidade de ser atualizado, mas este item vai ser visto melhor nos próximos tópicos deste material.
Product Burndown Chart
Postagens
Nenhum comentário:
Postar um comentário