Diretriz: Estimativa Ágil |  |
Esta diretriz explica os três principais conceitos da estimativa ágil e como eles se relacionam. Ela descreve os conceitos de estimativa ágil: tamanho, velocidade e esforço.
Relacionamentos
Elementos Relacionados | Atributos dos Requisitos Gestão de Projeto Lista de Itens de Trabalho Planejamento da iteração Planejar a Iteração Planejar o Projeto
Descrição Principal
### Estimativa Ágil Existem três principais conceitos que você precisa entender para fazer a estimativa ágil, veja [COH05] para mais informações: Estimativa de tamanho: fornece uma estimativa de alto nível para o item de trabalho, normalmente medida usando uma unidade neutra tal como pontos; Velocidade: diz-nos quantos pontos a equipe de projeto pode entregar em uma iteração; Estimativa de esforço: traduz o tamanho (medido em pontos) para uma estimativa de esforço detalhada usando normalmente as unidades de Dias Reais ou Horas Reais. A estimativa de esforço indica quanto tempo os membros da equipe necessitarão para completar os itens de trabalho atribuídos. #### Estimativa de Tamanho A estimativa de tamanho ágil é feita normalmente usando uma medida relativa chamada pontos. A equipe decide quão grande um ponto é, e baseado nesse tamanho, determina quantos pontos cada item de trabalho tem. Para fazer a estimativa rapidamente, você deve usar somente pontos cheios, 1, 2, 3, 5, 8, e assim por diante, ao invés de frações de ponto, tais como 0.25, ou 1.65 pontos. Para começar, olhe para 10 itens de trabalho, ou uma quantidade representativa, obtenha o menor tamanho de um ponto e então verifique todos os itens de trabalho restantes para atribuir-lhes uma estimativa de ponto relativa baseada nesse ponto. Note que estes pontos são usados para estimativas de alto nível, sendo assim não gaste muito tempo com os itens. Isto é mais crítico para itens de trabalho de prioridade mais baixa, para evitar o desperdício de esforços nas coisas que improvavelmente serão tratadas na iteração atual. Um grande benefício dos pontos é que eles são neutros e relativos. Vamos dizer que Ana é 3 vezes mais produtiva do que José. Se Ana e José concordarem que o item de trabalho A vale 1 ponto, e que o item de trabalho B é 5 vezes maior, eles podem rapidamente concordar que o item de trabalho B vale 5 pontos. Entretanto, Ana pode achar que o item de trabalho B pode ser feito em 12 horas, enquanto José acha que pode ser feito em 36 horas. Isso é normal, eles podem discordar sobre o esforço real necessário para fazê-lo, mas não devemos nos preocupar com isto neste momento, nós queremos somente que a equipe concorde com o tamanho relativo. Nós usaremos mais tarde a Velocidade para determinar quanto "tamanho", ou quantos pontos, a equipe pode trabalhar em uma iteração. Uma equipe de projeto pode dizer que um item de trabalho de um determinado tamanho vale 1 ponto. Outra equipe de projeto poderia estimar que o mesmo item de trabalho valesse 5 pontos. Isso é normal, contanto que esteja consistente dentro do mesmo projeto. Certifique-se de que a equipe inteira esteja envolvida na avaliação de tamanho, ou pelo menos que as mesmas pessoas estejam envolvidas em todas as suas estimativas de tamanho, para assegurar a consistência no seu projeto. Nós veremos como o conceito de velocidade reparará também esta discrepância de coisas com significados diferentes para diferentes equipes de projeto. Você pode também usar outras medidas de tamanho, onde a alternativa mais comum seja Dias Ideais. Veja [COH05], para mais informações. #### Velocidade A velocidade é uma importante métrica usada para o planejamento da iteração. Ela indica quantos pontos são entregues em uma iteração por uma determina equipe em um projeto. Por exemplo, uma equipe planejou fazer 20 pontos na primeira iteração. Ao final da iteração, eles observam que entregaram somente 14 pontos, então sua velocidade foi 14. Para a iteração seguinte, podem planejar menos pontos, vamos dizer 18 pontos, visto que eles acham que podem trabalhar um pouco melhor do que na iteração anterior. Nesta iteração, entregaram 17 pontos, dando-lhes uma velocidade de 17. Espere que a velocidade mude de iteração para iteração. Algumas iterações serão mais suaves do que outras, e os pontos não são sempre idênticos em termos de esforço. Alguns membros da equipe são mais eficazes do que outros e alguns problemas acabam sendo mais difíceis do que outros. Também, as mudanças na estrutura da equipe, aprendizagem de novas habilidades, mudança no ambiente de ferramentas, melhor trabalho em equipe, ou mais dispêndios com reuniões ou tarefas externas ao projeto irão afetar na velocidade. No geral, a velocidade normalmente aumenta durante o projeto à medida que a equipe melhora suas habilidades e se torna mais coesiva. A velocidade compensa as diferenças entre equipes em relação � quão grande um ponto seja. Vamos supor que a equipe de projeto Alfa e a equipe de projeto Beta são igualmente eficientes no desenvolvimento de software, e elas executam o mesmo projeto em paralelo. A equipe Alfa, entretanto, estima todos os itens de trabalho em 3 vezes os mesmos pontos que a equipe Beta estimou. Então a equipe Alfa estima os itens de trabalho A, B, C e D em 30 pontos e a equipe Beta estima os mesmos itens de trabalho em 10 pontos. Ambas as equipes entregam os 4 itens de trabalho na iteração seguinte, dando para a equipe Alfa uma velocidade de 30, e para a equipe Beta uma velocidade de 10. Pode parecer que a equipe Alfa seja mais eficaz, mas vamos olhar o que acontece quando eles planejam a iteração seguinte. Ambos querem fazer os itens de trabalho E e H, que a equipe Alfa estimou em 30 pontos, e a equipe Beta estimou em 1/3 dos mesmos pontos, ou seja, 10 pontos. Visto que uma equipe pode trabalhar tantos pontos quanto o indicado por sua velocidade, ambas podem trabalhar os itens E e H. O resultado final é que não importa quão grande seja um ponto, contanto que você seja consistente com a sua equipe. A velocidade também calcula a eficiência média de diferentes membros da equipe. Vejamos um exemplo: Vamos supor que Ana trabalha sempre 3 vezes mais rápida do que José e Jane. Ana poderá entregar 9 pontos por iteração, e José e Jane 3 pontos cada um. A velocidade dessa equipe de 3 pessoas será de 15 pontos. Como mencionado acima, Ana e José não conseguem concordar com a quantidade de esforço associado a um item de trabalho, mas podem concordar com a quantidade de pontos que ele vale. Visto que a velocidade da equipe é de 15, a velocidade traduzirá automaticamente a estimativa de pontos para quanto trabalho pode ser executado. Se você trocar os membros da equipe, ou se os membros da equipe se tornam mais ou menos eficientes, a velocidade irá mudar, e você poderá então trabalhar mais ou menos pontos. Entretanto, não é necessário alterar a estimativa de tamanho. O tamanho continua o mesmo e a velocidade lhe ajudará a calcular o volume que você pode entregar com a equipe que você tem para a iteração. #### Estimativa de Esforço A estimativa de esforço traduz o tamanho (medido em pontos) para uma estimativa de esforço detalhada usando normalmente as unidades de Dias Reais ou de Horas Reais. À medida que você planeja uma iteração, você irá deparar com um item de trabalho, tal como detalhar, projetar, implementar e testar um cenário, que pode ser estimado em 5 pontos. Visto que este item de trabalho, ainda é razoavelmente grande, divida-o em itens de trabalho menores, tal como quatro itens de trabalho separados para Detalhar, Projetar, Implementar e Testar, tanto a parte Servidor quanto a parte Cliente do cenário. Os membros da equipe são convidados a prontificarem-se para a realização das tarefas e, em seguida, detalham a estimativa de esforço real, medida em horas ou dias, para as suas tarefas. Neste caso as seguintes estimativas finais são feitas (com a pessoa responsável dentro do parêntese): Detalhar cenário (Ana): 4 horas Projetar o cenário (Ana e José): 6 horas Implementar e Testar a parte Servidor do cenário (José): 22 horas Implementar e Testar a parte Cliente do cenário (Ana): 12 horas Estimativa Total de Esforço para o Cenário: 44 horas Se as tarefas fossem atribuídas a outras pessoas, o tempo estimado poderia ser completamente diferente. Isto significa que não existe nenhuma forma de fazer estimativas detalhadas sem que você conheça quem irá executar o trabalho e quais os problemas reais que você irá enfrentar. Frequentemente, um pouco de análise e design do item de trabalho deve ser executado antes que uma estimativa razoável possa ser feita. Lembre-se que as estimativas ainda são estimativas, e que uma pessoa com uma tarefa atribuída deve sentir-se livre (e ser incentivada) à re-estimar o esforço necessário para terminar a tarefa, então manteremos uma visão realística do progresso de uma iteração.
Este programa e o material que o acompanha são disponibilizados sob a Eclipse Public License v1.0 que acompanha esta distribuição. Direitos Autorais do OpenUP.