Pontas de Iceberg do Caos no Desenvolvimento de Software
Por André Furtado
O cenário é contemporâneo, mas bem que poderia se tratar de mais uma batalha épica. De um lado, necessidades incompreendidas, especificações nebulosas, expectativas não-realistas, estimativas infundadas, quebras de comunicação, complexidades do domínio, conflitos de objetivos e mudanças à espreita, aguardando apenas a próxima oportunidade para o ataque. Do outro, equipes de desenvolvimento resistem, apoiadas em ferramentas (mesmo que artesanais), metodologias (mesmo que burocráticas ou genéricas demais) e em habilidades (mesmo que individuais) de seus membros. E o resultado desse confronto, por enquanto, não é nada encorajador...
Nunca esteve tão na moda apresentar os relatórios do The Standish Group, organização que reporta periodicamente estatísticas sobre sucesso e fracasso de projetos de desenvolvimento de software. Em um de seus relatórios mais recentes, é mostrado que apenas um terço de projetos de software podem ser considerados bem-sucedidos, enquanto o restante é cancelado e/ou apresenta uma falha crítica (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 código de fácil compreensão e modificação. A causa seria o constante aumento da complexidade e dinamismo dos problemas atacados em TI, o que não consegue ser superado pelas abordagens de desenvolvimento e pelo uso do ferramental atualmente disponível.
O problema é que falar sobre Crise de Software está na moda desde a década de 70. Quase quarenta anos se passaram, e ainda continuamos em busca de sua solução. Segundo o metodologista Grady Booch, "uma doença que dure tanto quanto esta, francamente, deveria ser chamada de normalidade".
É neste irônico cenário de normalidade, que apesar da rima nada inspira tranqüilidade, que gostaria de lhe oferecer, prezado leitor, as boas-vindas para esta coluna, intitulada Engenharia de Software Desmistificada. Neste e nos artigos subseqüentes, exploraremos conceitos, aspectos, técnicas, vertentes, ferramentas e exemplos dessa fascinante área da computação que é a Engenharia de Software, focada na criação e manutenção de sistemas através da aplicação de métodos e princípios da engenharia, ciência da computação, gerência de projetos e tantos outros domínios. O objetivo final é oferecer informação e orientação em meio ao mar de conhecimento que nós mesmos geramos para nos defender da Crise de Software:
| • | Metodologias, frameworks, guias e suas peculiares siglas (MSF, Pro.NET, XP, RUP, CMMI, PMBOK, etc.); |
| • | Boas práticas e suas siglas ainda mais peculiares: DRY (Don't Repeat Yourself), KISS (Keep it Simple, Stupid!), YAGNI (You Aren't Gonna Need It), etc.; |
| • | Atributos de qualidade, também conhecidos como "*dade" (extensibilidade, modularidade, flexibilidade, manutenibilidade, escalabilidade, etc.); |
| • | Por fim, o potencial de ferramentas de desenvolvimento (estarei particularmente interessado no Microsoft Visual Studio Team System e como ele concretiza os conceitos apresentados). |
Neste artigo, especificamente, gostaria de discutir um pouco sobre as causas do fracasso. O que impediria um projeto de software de cair na fatia dos um terço de projetos bem-sucedidos e não se tornar estatística para a Crise de Software?
Em primeiro lugar, é importante identificar o que não contribui para o fracasso. Jim Johnson, do The Standish Group, afirma que "quando um projeto falha, raramente a causa é técnica". Em outras palavras, o problema não é que .NET, Java ou outras tecnologias e ferramentas sejam instrumentos limitados para a construção de soluções de TI. A raiz comum para a maioria das falhas, na verdade, está na (ausência de) utilização de metodologias de desenvolvimento e como elas interagem com os indivíduos envolvidos em um projeto de software.
Por "metodologia de desenvolvimento", entende-se o conjunto de atividades, responsabilidades, artefatos (documentos, diagramas, código-fonte, etc.), orientações e boas práticas 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 não possuem uma padronização universal, podendo ser interpretados de maneira diferente quando em contextos distintos. Portanto, cabe ressaltar que não existe um único conjunto correto de definições. O importante é manter as definições consistentes ao longo de suas utilizações 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 críticos que a utilização de uma metodologia pode apresentar é ignorar o cliente e o usuário final em um projeto. A falta de envolvimento de ambos durante todo o desenvolvimento está diretamente relacionada ao fracasso. Requisitos e especificações incompletas, como conseqüência, também constituem uma deficiência-chave.
Por outro lado, falta de suporte executivo e pouca agilidade na resposta a mudanças também impactam bastante negativamente, de maneira decisiva, em um projeto de software. Ambos os fatores demandam articulação competente da gerência de projeto não apenas com a equipe como também com o ambiente externo ao projeto.
Outra causa do fracasso consiste na incapacidade de negociar conflitos entre os indivíduos envolvidos (equipe, cliente, usuários ou qualquer outro afetado pelo projeto). A esse problema, também estão relacionados:
| • | Objetivos nebulosos (não existe uma visão comum, compartilhada, entre o que o cliente deseja e o que a equipe do projeto está construindo); |
| • | Expectativas irrealistas (o cliente ou usuários, por exemplo, podem não estar cientes do escopo a ser atingido dentro dos recursos e prazos existentes); |
| • | Quebras de comunicação (como pouca documentação do processo e do produto em construção, informalidade excessiva e mal-entendidos, por exemplo). |
Por fim, a falta de recursos (humanos, financeiros, de infra-estrutura, etc.), assim como estimativas precárias de custos e de cronograma também são 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 domínio sendo abordado, a dinamicidade na geração de versões da aplicação em construção ou a presença de padrões e ferramentas. Entretanto, os itens listados ao longo desse artigo permitem uma visão 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 exercício, sugiro uma análise da metodologia de desenvolvimento utilizada por você ou sua empresa, de modo a identificar que eventuais pontos são falhos e/ou poderiam ser melhorados. É importante lembrar, entretanto, que não existe nenhuma "bala de prata" na Engenharia de Software, isto é, não há uma solução única para garantir o sucesso de todos os projetos para todas as organizações. Existem, sim, orientações 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 artifícios ao seu próprio contexto.
[]s
André Furtado
André Furtado é engenheiro de software pelo Centro de Tecnologia XML de Recife, mestrando e bacharel em Ciência da Computação pela Universidade Federal de Pernambuco (UFPE), um dos quinze Microsoft Student Ambassadors do Brasil (nível Gold), Certified Microsoft Solutions Framework Practitioner, Microsoft Certified Professional, Certified IBM-DB2 Specialist, Sun Certified Java Programmer 1.4 e campeão mundial / nacional da competição Imagine Cup 2005.
