PSP na prática: como medir e melhorar seu processo pessoal de software
Estimativas de desenvolvimento frequentemente começam com frases como “acho que termino hoje” ou “isso parece simples”.
Às vezes a previsão funciona. Em outras, uma tarefa pequena revela dependências, dúvidas e defeitos que multiplicam o tempo necessário.
O Personal Software Process, conhecido como PSP, propõe uma mudança: substituir parte da intuição por dados do próprio trabalho.
Ele leva a melhoria de processos para o nível individual.
O que o PSP procura desenvolver
O PSP ajuda o profissional a:
A proposta não é vigiar cada minuto nem transformar o trabalho em uma planilha infinita. O objetivo é conhecer o próprio processo para tomar decisões melhores.
Por que dados pessoais importam
Duas pessoas podem executar a mesma tarefa em tempos diferentes, não apenas por experiência, mas por ferramentas, domínio do contexto, estratégia de teste e tipo de dificuldade.
Uma estimativa baseada apenas na média de outra equipe pode não representar o seu trabalho.
Ao construir um histórico, o profissional começa a responder perguntas como:
Essas respostas são mais úteis do que a sensação genérica de estar “produzindo bem” ou “produzindo mal”.
A evolução do PSP
O PSP é apresentado em níveis incrementais.
PSP0 e PSP0.1 — medir o processo atual
O primeiro passo é estabelecer uma linha de base.
O profissional registra dados como:
A versão 0.1 acrescenta elementos como padronização de código e proposta de melhoria do processo.
Antes de melhorar, é necessário observar o que realmente acontece.
PSP1 e PSP1.1 — planejar e estimar
Com dados históricos, o profissional passa a estimar tamanho, esforço e cronograma de forma mais estruturada.
A comparação entre planejado e realizado gera aprendizado para o próximo trabalho.
PSP2 e PSP2.1 — gerenciar qualidade
O foco avança para prevenção e remoção antecipada de defeitos.
Revisões de projeto e de código ganham importância. A ideia é encontrar problemas antes da compilação ou dos testes, quando a correção tende a ser menos custosa.
PSP3 — trabalhar de forma cíclica
Trabalhos maiores são divididos em incrementos. Cada ciclo aplica práticas de planejamento, desenvolvimento e qualidade, reduzindo o risco de descobrir tarde demais que a estimativa ou a solução estava errada.
Um exemplo com uma extensão de navegador
Suponha que eu vá implementar o gerenciamento de atendimentos pendentes em uma extensão.
Eu poderia dividir o trabalho em fases:
Durante a execução, registraria algo assim:
Também classificaria os defeitos. Por exemplo:
Depois de algumas funcionalidades, padrões começam a aparecer.
Talvez eu descubra que sempre subestimo integração com páginas externas. Ou que revisões de código de 30 minutos evitam uma hora de correções. Esse conhecimento passa a orientar novas estimativas.
Defeito encontrado cedo custa menos
Uma das ideias mais importantes do PSP é que a fase de remoção influencia o custo.
Uma ambiguidade encontrada durante a leitura do requisito pode ser resolvida com uma conversa. Se ela chegar à produção, pode exigir investigação, correção de dados, nova versão, comunicação ao usuário e suporte.
Por isso, revisões não são uma atividade ornamental. Elas deslocam a descoberta de defeitos para fases mais baratas.
O mesmo vale para revisar a arquitetura antes de escrever centenas de linhas ou validar um fluxo com o usuário antes de construir todas as telas.
Métricas úteis
Algumas medidas ajudam a interpretar o processo pessoal.
Precisão da estimativa
Compara o esforço ou tamanho estimado com o realizado. O objetivo não é acertar sempre, mas conhecer o padrão do erro.
Densidade de defeitos
Relaciona a quantidade de defeitos ao tamanho do produto. Ela permite comparar trabalhos de dimensões diferentes, desde que a medida de tamanho seja coerente.
Rendimento de uma fase
Observa quanto dos defeitos existentes foi removido antes de avançar para a próxima etapa.
Tempo de correção
Mostra quanto esforço foi consumido para remover defeitos e quais tipos são mais caros.
A métrica só vale a pena quando apoia uma decisão. Registrar números sem analisá-los cria esforço, não aprendizado.
Evitando transformar o PSP em autocobrança
Medir o próprio trabalho exige cuidado.
Os dados não devem virar uma ferramenta de punição. Uma estimativa incorreta pode revelar uma dependência desconhecida, um requisito incompleto ou um tipo de tarefa novo. Isso é informação, não fracasso moral.
Também é importante não comparar mecanicamente pessoas diferentes. O PSP foi pensado para melhorar o processo do próprio profissional com base em seu histórico.
Uma aplicação saudável pergunta:
O que estes dados me ensinam sobre a forma como eu trabalho e qual pequena mudança posso testar no próximo ciclo?
Como começar sem burocracia
Uma versão simples pode usar uma planilha ou um arquivo com as colunas:
Para começar:
Depois de três ou quatro tarefas, o histórico já pode revelar tendências.
PSP e produtividade
Produtividade não é apenas escrever mais código em menos tempo.
Se a velocidade inicial gera defeitos e retrabalho, o ganho pode ser ilusório. O PSP trata planejamento e qualidade como partes da produtividade.
Um profissional melhora quando consegue entregar com mais previsibilidade, introduzir menos defeitos e aprender com o próprio desempenho.
Conclusão
O PSP transforma experiência em dados reutilizáveis.
Em vez de depender somente da memória e da intuição, o profissional registra como planejou, onde gastou tempo, quais defeitos introduziu e o que pode mudar.
A principal ideia é simples:
Medir não serve para provar que trabalhamos rápido. Serve para compreender como trabalhamos e melhorar o próximo ciclo.
Com este artigo, a série percorre três níveis da qualidade: o produto que avaliamos, o processo organizacional que sustenta as entregas e o processo pessoal de quem constrói software.
Este artigo organiza reflexões dos meus estudos na pós-graduação em Engenharia da Qualidade e Teste de Software. O PSP é apresentado de forma introdutória e prática, como ponto de partida para experimentação pessoal.