← Últimos artigos
💻 computer science

A Capacity-Aware Parr Model for Agile Projects

Este artigo propõe uma refatoração do modelo clássico de Parr, consciente da capacidade, que integra a demanda de esforço latente normalizada com trajetórias de capacidade observadas ou planejadas para prever o progresso de projetos ágeis, o tempo de conclusão e déficits de recursos sem assumir pessoal ilimitado.

Autores originais: Pedro E. Colla

Publicado 2026-07-03
📖 5 min de leitura🧠 Leitura aprofundada

Autores originais: Pedro E. Colla

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está planejando uma longa viagem de carro. Você tem um mapa que mostra exatamente quanto combustível você deveria queimar em cada etapa da jornada para chegar ao destino no horário previsto. Isso é o que os modelos de software tradicionais fazem: eles desenham uma curva dizendo: "Para concluir este projeto, você precisa de uma equipe enorme no meio, menos pessoas no início e menos pessoas no fim".

Mas aqui está o problema no mundo real (especialmente em equipes de software "Agile"): você não consegue contratar quem quer, quando quer. Sua empresa tem uma equipe fixa de cinco pessoas. Talvez elas só possam trabalhar 40 horas por semana. O mapa tradicional diz: "Você precisa de 20 pessoas no mês que vem!" mas seu chefe diz: "Não, você só tem cinco".

Este artigo propõe uma nova maneira de olhar para esse mapa. Em vez de tratar a curva como uma regra rígida para contratação, ele a trata como uma fome oculta por trabalho.

A Ideia Central: A "Fome" vs. A "Geladeira"

O autor, Pedro Colla, sugere que separemos duas coisas:

  1. A Fome (Demanda Latente): Esta é a "Curva Parr". Ela representa quanto trabalho o projeto naturalmente deseja realizar em qualquer dado momento. É como um estômago que fica com muita fome no meio do dia e menos fome pela manhã e à noite.
  2. A Geladeira (Capacidade): Isso é o que você realmente tem disponível. Talvez você tenha apenas um sanduíche (5 pessoas) quando o estômago quer um bife (20 pessoas).

O Jeito Antigo: Os modelos antigos assumiam que, se a curva dizia que você precisava de um bife, você deveria conseguir um bife, ou o projeto falharia. Eles tentavam forçar o tamanho da equipe a corresponder à curva.

O Novo Jeito (Este Artigo): O novo modelo diz: "Ok, o projeto está com fome de um bife, mas só temos um sanduíche. Nós comeremos o sanduíche. Faremos o máximo que o sanduíche permitir, mas não fingiremos que comemos o bife".

Como Funciona em Linguagem Simples

O modelo usa uma fórmula matemática simples para rastrear essa "fome". Ele faz três perguntas:

  1. Qual o tamanho da refeição completa? (Esforço total necessário).
  2. Como é a curva de fome? (Quando o projeto costuma ser mais intenso?).
  3. O que tem na geladeira hoje? (Quantas pessoas estão realmente disponíveis esta semana?).

O modelo então calcula:

  • Progresso: Quanto da refeição nós realmente comemos esta semana?
  • O Gap (Lacuna): Tivemos um "déficit de capacidade" (estávamos com fome, mas não havia comida)?
  • O Slack (Folga): Tivemos comida extra na geladeira que não precisamos comer?

A Analogia da "Previsão Contínua"

Imagine que você está dirigindo e checando seu GPS.

  • GPS Antigo: "Você deve dirigir a 100 mph para chegar às 17h". (Ignora o trânsito ou os limites de velocidade).
  • Este Modelo: "Você quer dirigir a 100 mph para chegar às 17h, mas o limite de velocidade é 60 mph. Portanto, você chegará mais tarde. Vamos recalcular seu horário de chegada com base nos 60 mph".

O artigo testa essa ideia usando dados de um projeto de software real (uma equipe de 5 a 8 pessoas trabalhando por 22 semanas). Eles dividiram os dados ao meio:

  1. Calibração: Eles usaram a primeira metade da viagem para ajustar a "curva de fome" para se adequar àquela equipe específica.
  2. Predição: Eles usaram a segunda metade para ver se o modelo conseguia prever o futuro baseando-se apenas no tamanho real da equipe, sem espiar os resultados finais.

O Que Eles Descobriram (e o Que Não Descobriram)

O artigo é muito honesto sobre o que alcançou:

  • Funciona internamente: O modelo rastreou com sucesso o progresso da equipe e identificou quando eles estavam "passando fome" (falta de pessoas) ou tinham "sobras" (capacidade extra).
  • É simples: Não tenta explicar por que a equipe é lenta (como má comunicação ou bugs). Apenas mede a lacuna entre o que o projeto precisa e o que a equipe pode fazer.
  • Não é uma bola de cristal mágica: Os autores admitem que testaram isso em apenas um projeto. Eles não podem dizer que funcionará para todas as empresas do mundo ainda. Eles precisam testar em muitos mais projetos para provar que é uma regra universal.

A Conclusão

Este artigo não inventa uma nova maneira de construir software. Em vez disso, inventa um painel de controle melhor para gestores.

Ele para de dizer aos gestores: "Você deve contratar 20 pessoas!" e começa a dizer: "O projeto está com fome de 20 pessoas, mas você só tem 5. Aqui está exatamente o quanto o projeto ficará mais lento, e aqui está exatamente quando você terminará se mantiver o tamanho da equipe em 5".

Ele transforma uma curva matemática rígida em uma ferramenta flexível que respeita a realidade dos recursos limitados.

Afogado em artigos na sua área?

Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.

Experimentar Digest →