14
Sinônimo de Conjectura Avaliação ou cálculo apro ximado de algo; estima, estimação. Estimat iva Parecer formado a partir de aparências, indícios ou probabilidades; suposição; hipótese;

Apresentação - Estimativa - Scrum

Embed Size (px)

Citation preview

Page 1: Apresentação - Estimativa - Scrum

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;

Page 2: Apresentação - Estimativa - Scrum

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.

Page 3: Apresentação - Estimativa - Scrum

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.

Page 4: Apresentação - Estimativa - Scrum

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).

Page 5: Apresentação - Estimativa - Scrum

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.

Page 6: Apresentação - Estimativa - Scrum

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.

Page 7: Apresentação - Estimativa - Scrum

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.

Page 8: Apresentação - Estimativa - Scrum

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

Page 9: Apresentação - Estimativa - Scrum

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....

Page 10: Apresentação - Estimativa - Scrum

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.

Page 11: Apresentação - Estimativa - Scrum

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).

Page 12: Apresentação - Estimativa - Scrum

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.

Page 13: Apresentação - Estimativa - Scrum

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.

Page 14: Apresentação - Estimativa - Scrum

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