Paradoxo de Schrodinger e Projetos de Software

Existe um paradoxo da física famoso conhecido como o “paradoxo do gato”, proposto pelo Schrodinger:

numa caixa fechada, que não podemos observar, temos um gato e um frasco de veneno revolver carregado (creio que é um revolver). Este revolver é disparado por frasco é quebrado quando partículas radioativas atingem um contador Geiger, e a pergunta que o Schrodinger nos faz é: qual a probabilidade do gato estar vivo uma hora depois da caixa ter sido fechada?

Onde está o paradoxo?

Bem, para o físico que está do lado de fora da caixa, a fórmula para a probabilidade do estado do gato é:

1/ ᵠ (gato morto) + 1/ ᵠ (gato vivo)

Se, no entanto, fizermos um furo na caixa, só temos duas possibilidades: o gato está morto, ou o gato está vivo.

Quando estamos num projeto, estamos na mesma situação do gato. Usamos uma metodologia (Scrum, MSF, RUP, etc.) e sabemos do estado do projeto (sucesso, atraso, cancelado, etc.). O estado é sempre único.

Como temos uma grande habilidade para, com poucos dados, inferir uma regra geral,  a partir da nossa experiência local (nossa história pessoal) passamos logo ao credo de que uma metodologia ou prática A é fundamental e garante o sucesso de um projeto, ou, ao contrário, que ela é uma tragédia e causa de todos os males. Porém, fazemos isto sem considerar o todo do que está acontecendo na indústria. Um projeto é sempre feito de um conjunto de pequenos fatos únicos e não repetitivos que ajudam a determinar sua (nossa) história, mas, na perspectiva geral, a história poderia probabilisticamente ser bem diferente.

Gosto de ter a minha visão histórica e pessoal, mas levo em conta também dados macros da indústria, que estão mais do lado da perspectiva do físico que está do lado de fora da caixa olhando para o todo das possibilidades.

Conto isto para estimular vocês a lerem livros como o “Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies” que relatam conclusões tiradas de estatísticas de projetos reais. Nele aprendi, por exemplo, que a metodologia ágil tem excelente influência em projetos de até 1000 pontos de função, mas que ,a partir daí, pode até se tornar maléfica. Aprendi também que PSP (Personal Software Process) e TSP (Team Software Process) são processos benéficos em qualquer tamanho de software, e assim por diante.

O autor não revela, infelizmente, seus dados para que possamos checar suas conclusões, mas, mesmo assim, vale a leitura.

Fica aqui a minha dica.