Pontas de Iceberg do Caos no Desenvolvimento de Projetos

Por Andr Furtado

O cenrio contemporneo, mas bem que poderia se tratar de mais uma batalha pica. De um lado, necessidades incompreendidas, especificaes nebulosas, expectativas no-realistas, estimativas infundadas, quebras de comunicao, complexidades do domnio, conflitos de objetivos e mudanas espreita, aguardando apenas a prxima oportunidade para o ataque. Do outro, equipes de desenvolvimento resistem, apoiadas em ferramentas (mesmo que artesanais), metodologias (mesmo que burocrticas ou genricas demais) e em habilidades (mesmo que individuais) de seus membros. E o resultado desse confronto, por enquanto, no nada encorajador... Nunca esteve to na moda apresentar os relatrios do The Standish Group, organizao que reporta periodicamente estatsticas sobre sucesso e fracasso de projetos de desenvolvimento de software. Em um de seus relatrios mais recentes, mostrado que apenas um tero de projetos de software podem ser considerados bem-sucedidos, enquanto o restante cancelado e/ou apresenta uma falha crtica (ou finalizado com atraso, ou custando mais do que inicialmente estimado, ou entregando menos funcionalidades do que havia sido previamente combinado com o cliente). Mais na moda ainda falar sobre Crise de Software, termo cunhado para descrever a dificuldade de se criar programas de computador corretos e com cdigo de fcil compreenso e modificao. A causa seria o constante aumento da complexidade e dinamismo dos problemas atacados em TI, o que no consegue ser superado pelas abordagens de desenvolvimento e pelo uso do ferramental atualmente disponvel. O problema que falar sobre Crise de Software est na moda desde a dcada de 70. Quase quarenta anos se passaram, e ainda continuamos em busca de sua soluo. Segundo o metodologista Grady Booch, "uma doena que dure tanto quanto esta, francamente, deveria ser chamada de normalidade". Neste artigo gostaria de discutir um pouco sobre as causas do fracasso. O que impediria um projeto de software de cair na fatia dos um tero de projetos bem-sucedidos e no se tornar estatstica para a Crise de Software? Em primeiro lugar, importante identificar o que no contribui para o fracasso. Jim Johnson, do The Standish Group, afirma que "quando um projeto falha, raramente a causa tcnica". Em outras palavras, o problema no que .NET, Java ou outras tecnologias e ferramentas sejam instrumentos limitados para a construo de solues de TI. A raiz comum para a maioria das falhas, na verdade, est na (ausncia de) utilizao de metodologias de desenvolvimento e como elas interagem com os indivduos envolvidos em um projeto de software. Por "metodologia de desenvolvimento", entende-se o conjunto de atividades, responsabilidades, artefatos (documentos, diagramas, cdigo-fonte, etc.), orientaes e boas prticas utilizadas para planejar, construir e implantar software. Algumas pessoas utilizam os termos "processo" ou "framework" no lugar de "metodologia"; entretanto, considero que esses termos possuem um outro significado e os introduzirei em momento mais adequado. Infelizmente, esse um aspecto da Engenharia de Software com o qual precisamos lidar: alguns de seus termos no possuem uma padronizao universal, podendo ser interpretados de maneira diferente quando em contextos distintos. Portanto, cabe ressaltar que no existe um nico conjunto correto de definies. O importante manter as definies consistentes ao longo de suas utilizaes e isso sempre ser realizado ao longo dos artigos desta coluna. Vamos retornar aos fatores que proporcionam caos no desenvolvimento de software. Um dos problemas mais crticos que a utilizao de uma metodologia pode apresentar ignorar o

cliente e o usurio final em um projeto. A falta de envolvimento de ambos durante todo o desenvolvimento est diretamente relacionada ao fracasso. Requisitos e especificaes incompletas, como conseqncia, tambm constituem uma deficincia-chave. Por outro lado, falta de suporte executivo e pouca agilidade na resposta a mudanas tambm impactam bastante negativamente, de maneira decisiva, em um projeto de software. Ambos os fatores demandam articulao competente da gerncia de projeto no apenas com a equipe como tambm com o ambiente externo ao projeto. Outra causa do fracasso consiste na incapacidade de negociar conflitos entre os indivduos envolvidos (equipe, cliente, usurios ou qualquer outro afetado pelo projeto). A esse problema, tambm esto relacionados: Objetivos nebulosos (no existe uma viso comum, compartilhada, entre o que o cliente deseja e o que a equipe do projeto est construindo); Expectativas irrealistas (o cliente ou usurios, por exemplo, podem no estar cientes do escopo a ser atingido dentro dos recursos e prazos existentes); Quebras de comunicao (como pouca documentao do processo e do produto em construo, informalidade excessiva e mal-entendidos, por exemplo). Por fim, a falta de recursos (humanos, financeiros, de infra-estrutura, etc.), assim como estimativas precrias de custos e de cronograma tambm so apontadas como causas recorrentes de fracasso em projetos de desenvolvimento de software. Obviamente, muitos outros fatores impactam no destino de um projeto, como a complexidade do domnio sendo abordado, a dinamicidade na gerao de verses da aplicao em construo ou a presena de padres e ferramentas. Entretanto, os itens listados ao longo desse artigo permitem uma viso geral das principais causas de fracasso pertencentes ao escopo "people & processes" (pessoas e processos) de um projeto, principal alvo de metodologias de desenvolvimento e da Engenharia de Software em geral. Como exerccio, sugiro uma anlise da metodologia de desenvolvimento utilizada por voc ou sua empresa, de modo a identificar que eventuais pontos so falhos e/ou poderiam ser melhorados. importante lembrar, entretanto, que no existe nenhuma "bala de prata" na Engenharia de Software, isto , no h uma soluo nica para garantir o sucesso de todos os projetos para todas as organizaes. Existem, sim, orientaes na forma de metodologias customizadas, guias e ferramentas, mas cada realidade uma realidade distinta e caber a voc (ou a um especialista contratado por voc) adaptar tais artifcios ao seu prprio contexto. []s Andr Furtado Andr Furtado engenheiro de software pelo Centro de Tecnologia XML de Recife, mestrando e bacharel em Cincia da Computao pela Universidade Federal de Pernambuco (UFPE), um dos quinze Microsoft Student Ambassadors do Brasil (nvel Gold), Certified Microsoft Solutions Framework Practitioner, Microsoft Certified Professional, Certified IBM-DB2 Specialist, Sun Certified Java Programmer 1.4 e campeo mundial / nacional da competio Imagine Cup 2005.