# Gestão de projetos de software

Planeamento, estimação com pontos, velocidade, burndown e gestão clássica contra ágil.

Página: https://resumos.rgo.pt/cadeiras/es/gestao-projetos/

Gerir um projeto é responder a três perguntas em permanência: o que falta fazer, quanto tempo vai demorar e se vamos chegar a tempo. A gestão clássica responde com um plano detalhado feito no início. A gestão ágil responde com estimativas revistas a cada sprint e um acompanhamento visual do progresso. Ambas precisam de números honestos.

## Planear e monitorizar

Planear é partir o âmbito em tarefas com dono e prazo, identificar dependências (o que bloqueia o quê) e marcar marcos verificáveis, como “início de sessão demonstrado ao dono do produto”. Monitorizar é comparar o feito com o planeado em cada ponto e decidir cedo: cortar âmbito, pedir ajuda ou renegociar o prazo. A decisão tardia é a mais cara, porque já gastaste o tempo e ficaste sem margem.

O instrumento ágil de monitorização é o **burndown**: um gráfico com o trabalho restante (eixo vertical) ao longo dos dias do sprint (eixo horizontal). Uma linha ideal desce do total até zero. Se a linha real está acima da ideal, a equipa está atrasada; se está plana durante dias, algo bloqueou; se cai de repente no fim, as tarefas foram atualizadas tarde e o acompanhamento falhou durante o sprint.

No gráfico, um sprint de 40 pontos tem a linha ideal a descer 4 pontos por dia. A linha real mostra 26 pontos restantes ao fim do dia 5, claramente acima da ideal: é o atraso do exercício desta página, apanhado a meio do sprint em vez de no fim.

![Burndown de um sprint de dez dias com 40 pontos: a linha ideal desce do canto superior esquerdo até zero no dia 10, e a linha real desce mais devagar, marcando 26 pontos restantes no dia 5.](https://resumos.rgo.pt/cadeiras/es/gestao-projetos/figura-1.svg)

## Estimar com pontos e velocidade

Estimar em horas é mentir com precisão: ninguém sabe se uma tarefa demora seis ou dez horas. As equipas ágeis estimam em **pontos de história**, uma medida relativa de esforço e incerteza. Uma história simples de referência vale 1 ou 2 pontos; outra que parece o triplo do trabalho vale o triplo dos pontos. O que interessa é a proporção, não o valor absoluto. A técnica habitual para convergir é o **planning poker**: cada membro mostra a sua estimativa em simultâneo e discutem-se as divergências, o que evita que a opinião do primeiro a falar arraste as outras.

A **velocidade** de uma equipa é a média de pontos concluídos por sprint. Com três sprints de 18, 22 e 20 pontos, a velocidade é:

$v = \frac{18 + 22 + 20}{3} = 20 \text{ pontos por sprint}$

Isto diz quantos pontos cabem no próximo sprint (cerca de 20) e quando termina um backlog: 100 pontos a 20 por sprint são cinco sprints. A velocidade mede-se, não decreta-se: impor “a partir de agora fazemos 30” não acelera nada, só estraga a previsão.

Confirma as contas tu próprio. O programa soma os três sprints, divide por três para obter a velocidade e divide o backlog pela velocidade, arredondando para cima porque meio sprint parado não conta.

```javascript
const sprints = [18, 22, 20];
let soma = 0;
for (const pontos of sprints) soma += pontos;
const velocidade = soma / sprints.length;
console.log("Velocidade: " + velocidade + " pontos por sprint");
console.log("Um backlog de 100 pontos demora " + Math.ceil(100 / velocidade) + " sprints.");
```

## Gestão clássica contra gestão ágil

**Plano:** detalhado no início, mudar custa.

**Requisitos:** fixos por contrato.

**Controlo:** cumprir o plano inicial.

**Cliente:** vê o produto no fim.

**Adequada a:** requisitos estáveis, contratos rígidos.

**Plano:** revisto a cada sprint, mudar é rotina.

**Requisitos:** ordenados por valor, evoluem.

**Controlo:** entregar valor a cada iteração.

**Cliente:** vê incrementos e decide o rumo.

**Adequada a:** requisitos incertos, feedback frequente.

Nenhuma vence sempre. Um contrato com âmbito fechado e preço fixo pede gestão clássica. Um produto novo, em que ninguém sabe ao certo o que os utilizadores querem, pede gestão ágil. Numa pergunta de comparação, ancora a escolha na estabilidade dos requisitos.

Como cai isto em teste

O exercício clássico dá-te histórias com pontos, a velocidade da equipa e um burndown, e pergunta se o sprint chega ao fim e o que cortar. O método é sempre o mesmo: soma os pontos planeados, compara com a velocidade, lê a posição da linha real e propõe cortar as histórias de menor valor primeiro.

## Exercício: ler um burndown e cortar âmbito

Um sprint de dez dias planeou 40 pontos. A velocidade histórica da equipa é 36 pontos por sprint. Ao fim do dia 5, o burndown mostra 26 pontos restantes quando a linha ideal marcaria 20.

1.  **Diagnóstico.** Faltam 26 pontos em 5 dias, ou seja, um ritmo de 5,2 pontos por dia, quando o ritmo necessário era 4 por dia. A equipa está atrasada cerca de 6 pontos, e a velocidade histórica (36, abaixo dos 40 planeados) já avisava que o sprint estava sobrecarregado.
2.  **Decisão.** É preciso cortar cerca de 6 pontos de âmbito. Olha para o backlog do sprint ordenado por valor: supõe que contém “bloquear conta após 5 tentativas falhadas” (5 pontos) e “mostrar força da palavra passe” (3 pontos). Corta a funcionalidade de menor valor imediato e renegocia com o dono do produto: o bloqueio por tentativas protege contra ataques e fica; o medidor de força, útil mas acessório, passa para o próximo sprint.
3.  **Lição.** O erro aconteceu no planeamento, ao aceitar 40 pontos com velocidade de 36. O burndown só revelou a meio o que os números já diziam no início. Registar isto na retrospetiva (“não planear acima da velocidade”) vale mais do que o serão extra para tentar recuperar o sprint.

## Para saber mais

*   [Criação e ordenação do product backlog, Atlassian](https://www.atlassian.com/agile/scrum/backlogs): como o dono do produto decide o que tem valor e o que fica para depois.

Na próxima página, [Requisitos](https://resumos.rgo.pt/cadeiras/es/gestao-projetos/requisitos-uml/), vais ver como escrever as histórias e os requisitos que alimentam este planeamento.