Dimensionamento de equipe e prazo em projeto de software sob restrição orçamentária
Uma equipe de 4 desenvolvedores mantém um sistema acadêmico em produção. O backlog priorizado tem 120 pontos de história. A velocidade média histórica da equipe é de 20 pontos por sprint de 2 semanas, mas 30% da capacidade é consumida por manutenção corretiva (bugs em produção) e suporte. O cliente exige entrega de todo o backlog em 6 meses (12 sprints). O gerente propõe contratar 2 desenvolvedores júnior, que levarão cerca de 3 sprints para atingir produtividade plena e, nesse período, consumirão 40% do tempo de um sênior em mentoria. O orçamento permite apenas uma contratação adicional ou a compra de uma ferramenta de testes automatizados que reduziria a manutenção corretiva de 30% para 15% da capacidade a partir do 2º sprint.
1. Calcule a capacidade efetiva atual e avalie se o prazo de 12 sprints é viável sem intervenção. Mostre os números.
Read the worked answer
Capacidade bruta por sprint: 20 pontos. Capacidade efetiva = 20 × (1 − 0,30) = 14 pontos/sprint. Em 12 sprints: 12 × 14 = 168 pontos de capacidade efetiva contra 120 pontos demandados. À primeira vista há folga de 48 pontos (~3,4 sprints de folga). Porém, o backlog de 120 pontos é apenas o trabalho novo; a manutenção já está descontada da capacidade. Logo, o prazo é viável no papel, com margem de ~28%. O risco está na variabilidade: se a manutenção subir para 45% em algum período, a capacidade cai para 11 pontos/sprint e o total em 12 sprints seria 132 - ainda suficiente, mas sem margem para imprevistos. Conclusão: viável, mas com pouca robustez a aumentos de defeitos.
2. Compare as duas opções (contratar 1 júnior vs. comprar a ferramenta de testes) e recomende uma, justificando com estimativas.
Read the worked answer
Opção A - 1 júnior: nos 3 primeiros sprints ele não agrega capacidade líquida plena e ainda consome 40% de um sênior. Estimando que o sênior responde por 1/4 da capacidade bruta (5 pontos), a mentoria custa 0,4 × 5 = 2 pontos/sprint durante 3 sprints (−6 pontos no total). Do 4º ao 12º sprint (9 sprints), supondo que o júnior entregue metade da velocidade média de um dev pleno (20/4 = 5; metade = 2,5 pontos/sprint), ganho ≈ 9 × 2,5 = 22,5 pontos, líquido de −6 → **+16,5 pontos** no horizonte. Opção B - ferramenta: manutenção cai de 30% para 15% a partir do sprint 2, ou seja, capacidade efetiva passa de 14 para 17 pontos/sprint nos sprints 2–12 (11 sprints). Ganho = 11 × 3 = +33 pontos. Além disso, a ferramenta reduz risco de regressão de forma permanente, enquanto o júnior aumenta o risco de defeitos no curto prazo. Recomendação: comprar a ferramenta, por entregar cerca de o dobro do ganho de capacidade, com efeito imediato e menor risco, e reavaliar a contratação depois que a base de testes estiver estável.
3. Que decisão de escopo/processo você tomaria se, no sprint 4, a manutenção subisse para 50% e o cliente recusasse reduzir escopo?
Read the worked answer
Com 50% de manutenção, a capacidade efetiva cai para 10 pontos/sprint. Restariam 8 sprints → 80 pontos, contra o saldo do backlog (120 − ~56 entregues nos 4 primeiros sprints ≈ 64). Há aperto, e a tendência é piorar se a causa dos defeitos não for tratada. Ações, em ordem: (1) atacar a causa-raiz dos defeitos - priorizar correções estruturais e testes automatizados, tratando a dívida técnica como item de backlog com dono; (2) separar capacidade reservando uma faixa fixa para manutenção e protegendo o trabalho novo, em vez de deixar a manutenção consumir tudo; (3) negociar com o cliente por transparência, apresentando a curva de capacidade e propondo entrega incremental com priorização MoSCoW, entregando o núcleo e postergando itens de menor valor; (4) só então considerar hora extra pontual, com risco explícito de aumentar defeitos (efeito contrário). Não se deve prometer o prazo original sem mudar escopo, qualidade ou capacidade: o triângulo está fechado.