Extreme Programming > Desenvolvimento de software tradicional


Desenvolvimento Tradicional

(...) o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

Você colocaria grande parte do seu dinheiro em um investimento que tivesse 70% de chances de dar prejuízo? Talvez não, mas supondo que você seja suficientemente corajoso e decida fazer isso, você acompanharia o seu investimento de perto, ou só se preocuparia com ele de vez em quando?

Essas perguntas têm muito em comum com a indústria de software e talvez você se interesse por elas, se tiver a oportunidade de apreciar alguns números levantados por uma empresa americana chamada Standish Group. Há pouco mais de uma década, ela vem produzindo um relatório chamado The Chaos Report, cujo exemplar do ano 2000, que pesquisou 280 mil projetos de software nos EUA, revelou que 72% deles falham devido a um dos seguintes fatores:

  1. Consomem mais recursos que o orçado;
  2. Consomem mais tempo que o estimado;
  3. Não entregam o que foi combinado;
  4. Todas as alternativas acima em conjunto.

Infelizmente a letra d é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que foram cancelados ("apenas" 64.400 projetos).

O Standish Group também informa, pesquisando o grau de utilização das funcionalidades dos sistemas que são colocados em produção, ter descoberto que, tipicamente, 45% das funcionalidades nunca são utilizadas pelos seus usuários e 19% delas raramente são usadas, totalizando 64% de funcionalidades que poderiam deixar de ser produzidas. Por outro lado, o mesmo estudo revelou que 7% das funcionalidades são usadas sempre e outros 13% são usados com frequência, conforme o gráfico apresentado abaixo. Assim, concluiu-se que o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

Percentual de Utilização de Funcionalidade

É possível fazer mais do que importa e evitar fazer o que ninguém vai usar. Conheça mais sobre Extreme Programming!

Comentários (3 até o momento)

  1. Eduardo — 25/11/2008 17:14

    Gostaria de saber a fonte da pesquisa que alimenta este gráfico, para que possa argumentar com os clientes.

  2. Rodrigo Nin — 19/02/2008 11:51

    Existem muitos bons argumentos contra o desenvolvimento tradicional, e este da inutilidade de funcionalidades não necessita incluir as funcionalidades raramente utilizadas. Mesmo com uso rarefeito, algumas funcionalidades são necessárias. Um exemplo gritante é a de "restore" do banco de dados, mas existem, freqüentemente, muitos tratamentos de exceção que devem ser previstos, embora pouco utilizados, sob pena de demandarem intervenções (muitas vezes perigosas) "do pessoal do computador" para resolver o problema.

    45% é mais que suficiente!

    Abraço

  3. Eduardo — 29/05/2007 13:18

    Acho que esse é o melhor argumento para convencer seu cliente a fazer um projeto de escopo negociável, pois mostra como pode doer no bolso dele!!!