Upload
reginaldo-neto
View
114
Download
1
Embed Size (px)
Citation preview
Sinônimo de
Conjectura
Avaliação ou cálculo aproximado de algo; estima, estimação.
Estimativa
Parecer formado a partir de aparências, indícios ou probabilidades;
suposição;hipótese;
A estimativa de esforço necessário para cumprir uma demanda (requisito/estória) é a base para o planejamento do projeto de software.
As estimativas fornecem dados que permite prever a quantidade de pessoas que serão necessárias, além do tempo e os custos do projeto.
Para determinar o tempo de desenvolvimento é necessário estimar a duração dos requisitos do software.
Estimativas da duração do desenvolvimento dependem não apenas do tamanho do software que é necessário produzir, mas também da produtividade dos desenvolvedores, por isto, é fundamental o acompanhamento das horas gastas por cada membro do time em cada requisito.
A estimativa de entrega de um produto – software, é baseada em Métricas, estas Métricas estão baseadas em:
1. Tamanho (complexidade);2. Duração (o tempo real gasto);3. Produtividade (a entrega de Valor/Complexidade por desenvolvedor) e; 4. Esforço (Necessidade de Hora/Desenvolvedor).
Como estimar melhor...o esforço...
1.Tamanho (complexidade)Para obter o tamanho, deve-se considerar a complexidade técnica para cumprir o requisito.
2. DuraçãoDepois de avaliar o tamanho, ou seja, o quão complexo pode ser a implementação, pensamos em quantas horas (seguidas, sem considerar pausas para o café ou banheiro, problemas, reuniões, etc...) podemos cumprir o requisito.
Usando o Planning Poker...
1.Após a leitura e discussão dos requisitos, cada membro do time apresenta a carta correspondente ao grau de dificuldade.
0 = Requisito Pronto100 = Maior grau de dificuldade possível
? = Requisito ainda obscuro – necessidade de contatar o PO ou cliente.
Usando o Planning Poker...
1.Após a leitura e discussão do requisito, cada membro do time apresenta a carta correspondente ao grau de dificuldade.
0 = Requisito Pronto100 = Maior grau de dificuldade possível
? = Requisito ainda obscuro – necessidade de contatar o PO ou cliente.
Esta atividade será repetida para todos os requisitos. Somaremos os pontos estimados em todos os requisitos e aí avaliaremos o tempo necessário para cumprir – Definimos então o Sprint (Time Box).
Para que possamos obter maior gestão, podemos adotar inicialmente Sprints de 1 a 2
semanas.
Se todos os pontos obtidos na estimativa não “couberem” na time box, poderemos mandar as
respectivas estórias de volta ao backlog do produto
Agora que já temos as ESTÓRIAS, o dimensionamento de COMPLEXIDADE e a nossa TIME BOX, é hora de autogerenciamento.
Escreveremos as TAREFAS necessárias para cumprir cada Estória... Estas deverão ter
critérios, como a possibilidade de mensuração, ou seja, assim como uma iteração entrega um
incremento, uma tarefa deve entregar um micro incremento... Distribuímos os pontos disponíveis
em nossas tarefas, utilizando as mesmas variáveis e estimativa....
Medição
Uma das coisas fundamentais é saber a nossa capacidade de entrega de pontos. Em Scrum, medimos a VELOCIDADE do time, em CMMi,
precisamos identificar as horas trabalhadas por cada membro, em cada requisito.
Não planejamos tarefas, mas, informamos o esforço empregado em sua execução...
Portanto, devemos informar, diariamente, a(s) tarefa(s) executada(s), com as respectivas horas.
Expondo a nossa agilidade
O gráfico de Burndown exibe a entrega desses micro incrementos, ou seja, o consumo de
pontos.
Ao final do dia, contabilizamos os pontos entregues por todos do time e “descontamos”
do que ainda faltam entregar.
Qualquer problema encontrado para executar uma tarefa deve ser relatados juntamente com
as horas da(s) tarefa(s).
Expondo a nossa agilidade
Problemas gerais (infraestrutura, saúde, reuniões não planejadas...) deverão ser
registradas em um post-it, na respectiva data.
O dia a dia...
•Os requisitos são discutidos nas reuniões de planejamento;
•Os requisitos são estimados;•As tarefas são escritas e recebem a pontuação;•Os requisitos são registrados no dotProject;•Os membros recebem um e-mail com o
requisito final + código para rastreabilidade;•Coloca-se a “mão na massa”;
•Ao final do dia (todos os dias), registra-se as horas trabalhadas por requisito, informando as
tarefas.
O dia a dia...
•Às 9h, reunião diária – O que foi/será feito? •Funcionalidades são comitadas a qualquer
momento – informa-se o ID do requisito;
“No processo de desenvolvimento de sistemas, funcionalidade (ou atividade) é
definida como um comportamento ou uma ação para a qual possa ser visualizado um
início e um fim; isto é: algo passível de execução”.
pt.wikipedia.org/wiki/Funcionalidade