Repensando o desenvolvimento de software
14 de outubro de 2009, 20:22Por que falham tantos projetos de criação de software? A metodologia tradicional de desenvolvimento de software, mais usada hoje, perde terreno para a utilização de metodologias ágeis inovadoras.
Por
Para início de conversa, farei uma introdução de como se desenvolve software hoje e apresentarei a metodologia que solucionará grande parte dos seus problemas durante a criação de uma aplicação.
O objetivo é que você conheça os problemas da metodologia de desenvolvimento de software mais usada atualmente. É de extrema importância que você dedique um tempo para perceber o porquê da necessidade de repensar o desenvolvimento de software tradicional e utilizar metodologias ágeis inovadoras.
Aceitar uma mudança de paradigma como a que será introduzida no final deste artigo exigirá bastante coragem de sua parte.
Pois bem, vamos ao que interessa. Antes de começarmos a discutir e refletir sobre qual a melhor forma de desenvolver softwares de qualidade e de maneira produtiva é preciso buscar uma resposta para a uma pergunta que frequentemente tem voltado à tona: por que uma grande porcentagem dos projetos de criação de softwares falham?
Modelo em cascata
Para chegar a uma colusão definitiva vamos analisar como a maioria dos softwares é desenvolvida hoje em dia. O modelo de desenvolvimento mais utilizado atualmente é conhecido como “modelo em cascata”. Ele funciona de forma puramente sequencial através da distribuição de tarefas específicas para pequenas equipes envolvidas no projeto.
Essa metodologia se parece bastante com a utilizada nas grandes fábricas, principalmente após a revolução industrial.
Apesar de não parecer, isso é um grande problema. Não é porque deu certo no processo industrial que dará certo no desenvolvimento de software. Outro erro comum é pensar na criação de um software como um procedimento de fabricação, criando a idéia da “fábrica de software”.
Para comprovar a total diferença entre como deve ser o desenvolvimento de software e como é o processo de fabricação nas indústrias do mundo todo, vamos entender como funciona o processo industrial.
Assim como no modelo em cascata, as fábricas utilizam a ideia de produção sequencial e divisão de tarefas específicas para cada profissional. Ou seja, em uma fábrica de tecidos esse processo funcionaria da seguinte forma: primeiro seria selecionada a matéria prima, depois feita à pintura, o corte e assim sucessivamente.
Para cada etapa de produção, existem profissionais capacitados para fazer um trabalho manual. Esse trabalho é basicamente mecânico, ou seja, ele aprendeu a fazer e simplesmente o faz. Ele não necessita sempre de um esforço intelectual constante para isso.
É manual ou intelectual?
Dessa forma, também acaba acontecendo no modelo em cascata. Já da pra imaginar onde está o problema no fracasso da maioria dos softwares produzidos nesse modelo. Partindo do principio de que o processo de fabricação não necessita de um trabalho intelectual e sim de um trabalho mais manual, vamos refletir se o processo de desenvolvimento de software é manual ou intelectual.
Quando se desenvolve um software seguindo esse modelo tradicional em cascata, os desenvolvedores ficam limitados a fazer o que foi definido por uma analista anteriormente. Isso torna o trabalho do desenvolvedor algo mais manual do que intelectual, o pode atrapalhar bastante.
Desenvolver software está mais ligado a ideia de desenvolver um livro, uma obra de arte do que produzir tecido. Portanto, deve ser um trabalho bem mais intelectual do que manual.
Talvez isso ainda não seja suficiente para te convencer de que esse modelo pode gerar muitos problemas, então vamos aprofundar um pouco mais.
O desenvolvimento em cascata é dividido em etapas sequenciais conhecidas como análise de requisitos, projeto, implementação, integração, teste e depuração, instalação e manutenção de software.
Vamos analisar, de maneira resumida, cada etapa e os problemas que elas podem causar no produto final.
Análise de requisitos
Vamos iniciar pela primeira etapa, a análise de requisitos. Nessa etapa o cliente apresenta suas necessidades para a equipe de análise que decidirá as funcionalidades do sistema. É quando o primeiro problema já aparece. Normalmente o cliente apresenta algo completamente abstrato como: “Eu quero uma loja online”. A partir disso os analistas é que decidirão quais funcionalidades essa tal loja terá.
Todos sabem que os clientes nunca pensam em necessidades da forma como analistas pensam. Ou seja, o sistema terá funcionalidades que para o cliente não são tão necessárias, assim como não terá as funcionalidades que são realmente necessárias ao cliente.
O projeto
Segunda etapa, o projeto. É exatamente nessa etapa que começa um dos maiores problemas desse modelo - a falta de comunicação. O processo de desenvolvimento vira um verdadeiro telefone sem fio.
Durante essa etapa, os projetistas irão documentar o sistema pelo que receberam dos analistas. Surge outro problema. Quase sempre a análise feita pelos analistas não é suficientemente concreta para fazer com que os projetistas criem uma documentação realmente significativa de como o sistema deverá funcionar.
Implementação
Chegamos à terceira etapa, implementação. Aqui começa o estresse. Os programadores recebem a documentação dos projetistas e começam a criar as funcionalidades. Mais um problema. Os programadores desenvolvem todo o software com base em um documento (já bem diferente do que o cliente gostaria). Mas não para por ai. Pela falta de comunicação que existe entre o cliente e o desenvolvedor, o software termina se tornando algo totalmente diferente do que o cliente imagina que receberá no final do projeto. Ele não ficará nem um pouco feliz em saber que todo o dinheiro que investiu está indo pra lata do lixo.
Integração
Quarta etapa. Como os programadores se dividem para desenvolver partes diferentes do software, é necessário que exista uma etapa só para integrar essas partes. Encontramos outro problema. Programadores pensam diferentes e geralmente tem dificuldade em se comunicar bem com outros programadores por medo de ter um código ruim ou se mostrar inexperiente em determinadas áreas. Isso, além de ser uma bobagem, é preocupante na hora de integrar o sistema e pode gerar códigos difíceis de reutilizar. Além disso, pode criar as chamadas ilhas de conhecimento na equipe, onde alguns programadores conhecem bem uma parte do código, mas não conhecem nada sobre a outra parte. Imagine se um sair da equipe de repente.
Teste e depuração
Em fim chegamos à quinta etapa. Tirem as crianças da sala. Esta é a etapa mais complicada, chata e preocupante nesse modelo de desenvolvimento. Testes e depuração. É nessa parte que as maiores dores de cabeça começam a surgir em toda a equipe. A partir de agora é só problema, problema e problema. Nesse modelo de desenvolvimento o custo de alteração aumenta exponencialmente a cada minuto que passa e para chegar a esta etapa já se passaram muitas e muitas horas, dias ou meses.
Como o sistema foi todo desenvolvido sem testes, só agora aparecem os erros. Acreditem, eles muitas vezes não são corrigidos. Isso quando os projetos já não fracassaram antes dessa parte. O porquê disso é fácil de explicar.
Quando se tem milhares de linhas de código, corrigir um erro pode levar meses ou até anos. E como tempo é dinheiro, no desenvolvimento de software isso se torna muito custoso. Para que você possa entender melhor, seria como se você criasse um ônibus espacial e quando fosse testar ele explodisse por culpa de um simples parafuso.
Não é necessário comentar as outras etapas, já que na maioria dos casos os projetos nem chegam nelas. Acabam fracassando na etapa de testes.
A solução?
Qual a solução para que isso não aconteça?
Você não deve se limitar a esse modelo de desenvolvimento só porque ele é o mais usado. Ao contrário, você deve abrir a sua mente para conhecer e estudar novas metodologias de desenvolvimento de software com qualidade e de forma produtiva. Ainda discutiremos muitos sobre essas metodologias ágeis.
Para quem se interessou em se livrar desses problemas e desenvolver softwares de qualidade, acompanhem os próximos textos. Em breve estarei postando sobre eXtreme Programming ou simplesmente XP, uma metodologia de desenvolvimento ágil com valores na comunicação, simplicidade, feedback e coragem.
XP parte do princípio de que desenvolver software de qualidade está totalmente relacionado com a comunicação entre o cliente e o desenvolvedor, além de buscar encurtar o espaço de tempo entre a codificação e a entrega das funcionalidades, tentar fazer todos trabalharem em todo o código, entre outras características.
Uma característica do XP que pode deixar você um pouco confuso no início é conhecida como TDD - desenvolvimento guiado por testes.
TDD consiste em criar testes antes de desenvolver. Como assim? Vou testar algo que ainda não existe? Exatamente.
Primeiro são criados os testes de cada funcionalidade ainda não existente. Logicamente elas vão falhar. Aí entra o desenvolvedor para criar um código suficiente para que o teste valide e passe. Com isso você consegue códigos melhores, mais simples, com menos linhas e que fazem apenas o necessário, diminuindo em 90% a probabilidade de erros futuros.
Ufa… Se você foi guerreiro e chegou ao final deste texto enorme, parabéns. Provavelmente você deve ter ficado bastante curioso para conhecer mais sobre as metodologias ágeis. Mas seria querer demais que você aprendesse tudo isso de primeira.
Por isso nos próximos textos vamos apresentar uma metodologia de desenvolvimento ágil capaz de desenvolver, em apenas três meses, softwares que costumam ser desenvolvidos em três anos. Pois é, o tal do Extreme Programming é capaz de ajudar a realizar façanhas como essa. Aos poucos vamos ver outros detalhes do XP, para não tornar o assunto muito confuso.
Acompanhe, vamos tentar explicar como o XP funciona e, dessa forma, ajudar você a eliminar de vez a probabilidade de fracasso no seu projeto. XP vai mudar sua vida profissional para melhor. Acredite! [Webinsider]
.
Acompanhe o Webinsider no Twitter
.
1° C'est moi Data: 14/10/2009 às 8:58 pm
Atividade:
Cidade:
Não me sai da cabeça a suspeita que essas novas metodologias e regras que surgem todos os dias são necessárias devido a popularização da informática.
Cada dia chegando ao mercado gente menos preparada e o pior: sem espírito crítico, reflexão sobre o que faz.
Então passa a ser necessário regras e mais regras.
Começa a parecer aqueles avisos em eletrodomésticos americanos:
“Não coloque a mão dentro do liquidificador quando ele estiver ligado.”
“Animais vivos podem se machucar se colocados dentro do micro-ondas ativado”.