Gestão de projetos de software

A reserva completa exige regras acordadas, serviço, ecrã e integração. Fazer o ecrã depressa não antecipa a entrega se o serviço ainda o bloquear. Planear identifica estas dependências e estima quando o resultado pode ficar pronto.

Monitorizar é observar o que acontece; controlar é tomar medidas com base nessa observação. Um plano útil permite detetar um problema enquanto ainda podemos mudar o trabalho.

Âmbito, tarefas e dependências

O âmbito define o que entra e o que fica fora do projeto. Na primeira versão da aplicação queremos consultar salas, reservar e cancelar. Pagamentos e reservas de equipamento ficam fora.

Podemos decompor o trabalho em tarefas, identificar dependências, responsáveis, durações estimadas e marcos. Um marco é um ponto de verificação, como uma reserva completa demonstrada num dispositivo. Não é apenas “fim da semana”.

O caminho crítico é o caminho de maior duração numa rede de dependências e determina a menor duração do plano sob as hipóteses usadas. Considera estas tarefas:

Tarefa	Duração	Só começa depois de
A, acordar regras	2 dias	Nada
B, construir serviço	4 dias	A
C, construir ecrã	3 dias	A
D, integrar e validar	2 dias	B e C

Segue os traços mais grossos de A a B e D. Repara que D espera pelas duas tarefas, mas C pode terminar um dia mais tarde sem adiar D.

Calcula por passos. A começa no dia zero e termina no dia dois. B vai de dois a seis. C vai de dois a cinco. D só começa quando B e C terminam, por isso começa no dia seis e termina no dia oito.

O caminho A, B, D dura $2+4+2=8$ dias, e o caminho A, C, D dura $2+3+2=7$ dias; a duração mínima é oito dias, não a soma de todas as durações, 11. C tem folga de $8-7=1$ dia, e um atraso de dois dias em C cria um caminho de nove dias e torna-o crítico.

Riscos e reservas

Um risco é uma possibilidade incerta que pode afetar os objetivos. Um problema já ocorrido é uma situação a resolver, não apenas um risco futuro.

Para cada risco, regista a causa, a consequência, sinais de ocorrência, uma resposta e quem o acompanha. Se a API de salas puder limitar pedidos, fazemos uma experiência, medimos o limite e planeamos uma alternativa.

A exposição simplificada é $p \times I$, com probabilidade $p$ e impacto $I$. Uma probabilidade de 0,25 de causar oito dias adicionais dá dois dias de exposição esperada. Isso ajuda a comparar riscos, mas não garante que o atraso será dois dias. Um evento raro e grave pode exigir atenção mesmo quando o valor médio é baixo.

Estimar

Uma estimativa é uma previsão baseada em informação e hipóteses. Pode usar analogia com trabalho anterior, julgamento de especialistas, decomposição em tarefas ou modelos calibrados com dados. Indica o que inclui e qual é a incerteza.

Pontos de história exprimem tamanho relativo, considerando esforço, complexidade e incerteza segundo a convenção da equipa. No projeto, a escala usada é uma Fibonacci modificada: 1, 2, 3, 5, 8, 13, 20, 40 e 100. Não são horas universais. Uma equipa pode usar uma história conhecida como referência e comparar as restantes.

No planning poker, as pessoas estimam individualmente antes de revelar os valores. Quando aparecem 3 e 8 pontos, discutem as hipóteses. Uma pessoa pode estar a contar apenas o ecrã, enquanto outra inclui a integração e os erros de rede. O resultado útil é esclarecer o trabalho, não escolher uma média sem conversa. As tarefas do Sprint podem estimar-se em horas para acompanhar o dia a dia; os pontos alimentam a velocidade. Não converts pontos em horas por uma taxa fixa: cada nível responde a uma pergunta diferente.

Uma história demasiado grande deve ser dividida em resultados úteis. “Fazer todos os ecrãs” não é a mesma divisão que “consultar disponibilidade de uma sala”: a segunda pode atravessar ecrã, regras e dados, entregando uma capacidade verificável.

Velocidade e previsão

A velocidade é a quantidade de trabalho concluído por iteração, medida na unidade usada pela equipa. Se só contam itens Done, trabalho quase concluído não acrescenta pontos.

Em três Sprints comparáveis, a equipa concluiu 18, 22 e 20 pontos. A média é

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

Um backlog de 100 pontos sugere cinco Sprints à velocidade média, e usando os extremos observados a previsão simples varia entre $\lceil100/22\rceil=5$ e $\lceil100/18\rceil=6$ Sprints.

Não é um intervalo estatístico de confiança: pressupõe capacidade, critérios de conclusão, estimativas e âmbito comparáveis. Férias, novas dependências e alterações de âmbito exigem atualizar a previsão. Não compares a produtividade de equipas pelas suas velocidades, pois podem atribuir valores diferentes ao mesmo trabalho.

Ler um burndown

Um burndown mostra o trabalho restante ao longo do tempo, e a linha ideal linear é uma referência, não uma lei sobre o ritmo de execução. Num Sprint de dez dias com 40 pontos, a referência linear no fim do dia cinco é 20; se restarem 26, precisamos primeiro de saber se o âmbito e as estimativas mudaram.

Situação no dia cinco	Conta do trabalho concluído	Resultado
Âmbito e estimativas estáveis	$40-26$	14 pontos
Entraram 10 pontos, sem outras mudanças	$40+10-26$	24 pontos

O mesmo valor restante pode corresponder a progressos diferentes. No primeiro caso, estamos seis pontos acima da referência, mas isso não demonstra que cortar seis chega para terminar.

Restam 26 pontos e cinco dias, o que exigiria uma média de $26/5=5{,}2$ pontos concluídos por dia. Se a equipa repetisse os 14 pontos concluídos nos primeiros cinco dias, sobrariam $26-14=12$. Também esta extrapolação é uma hipótese: as histórias terminam em blocos e os bloqueios ou a capacidade podem mudar.

A decisão começa por olhar para itens, bloqueios, capacidade restante e Sprint Goal. Os Developers e o Product Owner podem ajustar o âmbito preservando o objetivo e a qualidade. Um burnup, que mostra trabalho concluído e âmbito total, ajuda a distinguir progresso de crescimento do âmbito.

Trabalho em curso

O WIP, work in progress, é o trabalho começado e ainda não concluído. Abrir muitos itens pode atrasar o momento em que algum fica utilizável, mesmo sem mudar a quantidade total de trabalho.

A simulação considera quatro itens de três unidades cada, todos disponíveis no início. A equipa executa uma unidade por dia e alterna entre os itens em curso. Quando termina um item, começa o seguinte se ainda houver trabalho. Não há dependências, diferenças de tamanho ou custo de alternância.

Com limite um, A termina no dia 3, B no 6, C no 9 e D no 12. Com limite quatro, a equipa dá a primeira unidade a cada item nos dias 1 a 4, a segunda nos dias 5 a 8 e a terceira nos dias 9 a 12.

Limite	Dias de conclusão de A, B, C e D	Primeiro resultado	Conclusão média desde o início
1	3, 6, 9, 12	Dia 3	$(3+6+9+12)/4=7{,}5$ dias
4	9, 10, 11, 12	Dia 9	$(9+10+11+12)/4=10{,}5$ dias

O último item termina no dia 12 nos dois casos, mas o foco disponibiliza o primeiro resultado mais cedo. A média conta dias desde o início da simulação. Não é o tempo médio entre começar e terminar cada item, porque com limite um alguns só começam mais tarde.

O modelo isola a alternância; não demonstra que todas as equipas devam trabalhar num único item. Trabalho bloqueado ou competências distintas podem justificar outro limite. No projeto, o quadro sugere um limite igual ao número de membros ou pares da equipa.

Gestão clássica e ágil

A gestão preditiva detalha antecipadamente o trabalho conhecido e controla os desvios. A gestão ágil usa objetivos, prioridades e planos de curto prazo revistos com evidência. Ambas precisam de riscos, recursos e decisões honestas.

Uma data fixa pode exigir variar o âmbito. Um requisito obrigatório pode exigir mais tempo ou outra solução. A equipa deve tornar essas escolhas explícitas, em vez de esconder o desvio em estimativas artificialmente baixas.