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 que, pesquisando o grau de utilização das funcionalidades dos sistemas que são colocados em produção, foi 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. 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.

O Manifesto Ágil

Nem todos os que trabalham na indústria de software têm conhecimento destes números, mas praticamente todos percebem, ainda que intuitivamente, que muita coisa é feita de forma errada e ineficaz, gerando problemas que não parecem ter fim. Existem inclusive piadas citando que nós estamos aqui para resolver os problemas que nós mesmos criamos.

Há alguns anos, um pequeno grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de ski, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre pareciam ter sido respeitados quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década. A mais conhecida delas é o Extreme Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos.