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
.
Dyego Luz
Dyego Luz (dyego@sitesfeitos.me) é fundador do Sitesfeitos, estudante de administração na UFRN onde cursou também ciência da computação. Fascinado por desenvolvimento de aplicações web, marketing digital e empreendedorismo. Mais no Twitter (@sitesfeitos) e no Facebook.
20 respostas
Oi,tenho 15 anos e estou no 2° ao do ensino médio e ultimamente tenho pensado em cursar Ciência da Computação.Sou bom em matemática e física e gosto de interagir nessa área.Queria saber como funciona esse curso,qual a melhor faculdade(pode ser paga,a FEI talvez?) e se eh bom eu fazer um curso técnico básico de desenvolvimento de software? Agradeço
Sou totalmente adepto aos métodos ágeis, de fato como já diz o nome, essa forma de desenvolver agiliza todo o processo. No entanto acredito que o modelo em cascata dificilmente vai morrer, na verdade, a cada interação do ágil acontece uma cascata, se pensarmos bem, pois as etapas pertinentes à cascata precisam acontecer de alguma forma, a análise, arquitetura, desenvolvimento, testes, homologação, etc.
Não existe nada de novo no ágil, ele é tão velho quanto a cascata, mas só veio a se popularizar nos últimos anos.
Algo muito bacana que o ágil tem é permitir que a equipe multidisplinar se interaja, isso evita problemas futuros por questões de comunicação, além de trazer todos para a maior parte do processo.
Seria o mesmo que descartar os documentos da Análise Estrutural e Essencial, só porque o modelo é Orientado a Objetos. Muito bacana a UML, mas descartar um DFC, DFD, uma lista de eventos, lista de requisitos funcionais e não funcionais seria jogar fora um conhecimento preciosíssimo.
Acredito que tudo é usual e válido e devem ser usados conforme a necessidade e contexto.
O próprio SCRUM para funcionar bem deve ser aplicado levando em consideração a cultura da empresa, a cultura das pessoas e seria melhor se fosse adaptado a essa realidade.
Rodrigo, essa questão sobre as metodologias ágeis serem ideais, vai muito da experiência usando ou de pessoas que a usam. Todos que conheço e que usam da maneira correta, entendendo o porque de usa-las e a filosofia por trás se deram muito bem usando.
Abraço,
Dyego Luz
Dyego,
Artigos como esse são de grande valia para a formação profissional de estudantes como eu. Afinal durante a graduação é tudo muito lindo e teórico. Discussões, como a que está ocorrendo nos comentários, contribuem bastante para o desnvolvimento de uma visão crítica, muito importante em uma carreira profissional.
Finalizando, gostaria de ressaltar que nada é 100%. Então, não se esqueça de relatar os contras das metodologias ágeis.
Dyego,
Acho interessante esta idéia de comparação entre as metodologias de desenvolvimento de software pois sou, meio que interessadíssimo neste tipo de assunto.
Até hoje ouço de diversos métodos de desenvolvimento e que cada um com sua particularidade traz ganhos, mas não consigo enxergar detalhes práticos na aplicação deles na empresas.
Será mesmo que metodologias ágeis são o ideal ?
Será que ainda não chegamos a uma forma de garantir o bom desenvolvimento de software com bons profissionais, com uma base de conhecimento científico e técnológico ?
Dyego, é preciso ter muita cautela quando falamos por isso que os projetos de software falham pois pode parecer que as metodologias ágeis fazem verdadeiras mágicas nas empresas de software e isso você sabe que não é verdade.
Na minha humilde opinião fazer uma junção de metodologias ainda é a melhor solução para as empresas.
Abraços
Flávio Elorza obrigado pelos comentários, entendi o que você disse e concordo em partes, são exatamente comentários desse tipo que engrandecem as discussões sobre esses assuntos!
Abraço,
Dyego Luz
Dyego,
Entendi perfeitamente seu texto e, antes de mais nada achei o conteúdo bem válido.
No entanto, acho que não há mais tanta demanda para grandes projetos de sistemas, isto posto metodologias como análise estruturada de sistemas, RUP e outras que se baseiam em um modelo esperial (e não cascata como diz) tornam-se improdutivas em face ao modelo ágil – que suporta muito bem projetos menores.
Por fim, penso que não existe uma receita de bolo ou o ovo de colombo, onde basta aplicar uma metodologia e pronto, mas sim a combinação delas adequado a proposta e a condição da empresa.
Por fim, vale lembrar que a essência continua a mesma, isto é fazemos software para atender requerimentos de negócio e não metodologias.
É isso e um grande abraço.
Flávio
Muito bom artigo, e vem de encontro a nossa adoção do XP na empresa. XP é uma forma totalmente nova de pensar e equacionar os problemas. XP a primeira vista, parece algo sem pé nem cabeça, idiot e que jamais vai funcionar, mas que quando você vai testando e entendo a metologia ágil, no final, sempre sobra a pergunta: Porque eu não uso isso a muito mais tempo?.. É simplesmente fantástico o grau de produtividade e de acertividade no projeto, melhoramos muito isso na empresa.. Estou amando XP, tem muito pela frente ainda, mas o que já botamos em prática, ficou jóia.
Abraço
Valeu Dyego
Mesmo fazendo uma relação com a engenharia existem algumas características que me fazem ver o processo de desenvolvimento de um software como algo diferente disso e mais próximo a uma produção artística. Nenhum cliente pede algo como Da pra colocar essa casa um pouco mais pra esquerda depois de pronta. Porém esse tipo de coisa acontece com freqüência e projetos de software. E assim como acontece na criação de livros entre outras artes, no software é sempre importante criar o software, repensando tudo sempre e refatorando códigos entre outras praticas que são mais parecidas nos processos de criações artísticas. Mudanças sempre acontecerão durante esse processo, a grande ?sacada? é está preparado para elas sempre que forem necessárias. Por exemplo, quando se escreve um livro não se escreve tudo em uma ordem sem voltar atrás e alterar parágrafos, se escreve fora de ordem geralmente. Por essas e outras que gosto de comparar o desenvolvimento de software a um processo de criação artística. Sobre ser a salvação de todos problemas… Vejo como uma salvação para os problemas relacionados acima no texto. Lógico que sempre existirão problemas nos projetos de software e que dificilmente serão resolvidos mas eles podem ser minimizados utilizando metodologias ágeis.
Estou adorando o feedback de vocês em relação aos textos, gosto bastante de poder ouvir outras opiniões e discutir sobre vários temas. Só assim nossa comunidade pode se desenvolver e se atualizar com as novas tecnologias, metodologias ou qualquer coisa que possa surgir para melhorar nosso trabalho aumentando nossa produtividade e qualidade dos nossos produtos.
Abraço,
Dyego Luz
Diego,
Um bom resumo sobre os problemas da metodologia cascata, só acho arriscado dizer que metodologias ágeis são a salvação do mundo e solução de todos os problemas. Penso em produção de software muito mais análoga a construção em engenharia, do que processos fabrís. Cada software é único, e sua produção esta inserida em um cenário, esses fatores devem ser analisados para só então determinar a metodologia adequada.
Olá Diego,
Aguardo ansioso por seus posts. Venho lendo alguns artigos a respeito do desenvolvimento ágil e de fato ele vem melhorar e muito nossa área.
Seus artigos serão de grande valia para qualquer desenvolvedor que queira melhorar a forma como trabalha.
Abraços.
Cara, o que procurei mostrar são as ?vantagens ? em desenvolver software utilizando metodologias ágeis. No próximo artigo vou introduzir o desenvolvimento ágil de software e vocês verão que o que torna o XP, scrum, ou qualquer metodologia ágil utilizada ser tão interessante e produtiva é a filosofia por traz e não apenas as práticas como simples regras. Sobre os dados que comprovam a eficácia do scrum, eu não tenho dados diretos, porém possuía gráficos que comprovam a ineficiência dos projetos de softwares desenvolvidos no Brasil (utilizando a idéia do desenvolvimento em cascata) e como o manifesto ágil veio para reformular a forma como se desenvolve software e tentar ?corrigir ? os problemas existentes na maneira ?trabalhosa e arriscada? que se desenvolve software tradicionalmente. Tudo isso sem falar que a ineficiência dos projetos de softwares no Brasil reduziu com a utilização de metodologias ágeis. Como ocorre no manifesto ágil, devemos nos preocupar mais com pessoas e não ferramentas ou documentos abstratos. Além de tudo isso, se observamos o texto do ?criador? do modelo em cascata vamos ver que ele mesmo fala que esse modelo provavelmente apresentará muitas falhas e nas paginas seguintes apresenta soluções que estão muito próximas das metodologias ágeis. Mas parece que todos observaram apenas a primeira pagina escrita.
Leiam:
http://pt.wikipedia.org/wiki/Modelo_em_cascata
http://agilemanifesto.org/
http://www.manifestoagil.com.br/
PS: Não achei os dois gráficos sobre os fracassos dos projetos de software ( andei formatando o notebook a um tempo ) e o que evoluiu nos últimos anos com a introdução as metodologias ágeis. A evolução ainda não e extraordinária mais já existe. Seria ótimo, se alguém conseguir achar na net os gráficos, postar nos comentários deste artigo. Aconselho também que vocês leiam o artigo do Royce, citado nesse texto da Wikipédia, para entender como ele apresentou o que seria chamado de modelo em cascata e como ele próprio definia ?ser um risco e um convite para falhas?.
Att,
Dyego Luz
Dyego, voçe tem dados que comprovam a eficácia do scrum ? O que entende por falha?
Processo de software é um processo construtivo como todos, é de fato como uma fábrica que produz o que foi especificado e qualifica as entregas produzidas.
Vale lembrar que se o resultado de requisito é ruim não é culpa do método em cascata e sim do analista de sistemas que é fraco tecnicamente, da mesma forma vale para a implementação e testes.
TDD não é absolutamente nada de novo. Voçe conhece algo chamado teste de mesa?
sds,
Flavio
Artigo muito bom. Parabéns!!!
Douglas na verdade o XP e Scrum são duas metodologias que se complementam, a XP está mais para a parte de desenvolvimento em si e o Scrum na parte de gerenciamento. O mais indicado seria trabalhar com as duas, e isto é o legal das metodologias ágeis, nada é fixo, você pode até pegar alguma característica que ache interessante de outra metodologia e trabalhar também no seu projeto.
Existe uma outra metodologia menos famosa a OpenUP, que pelo que lí é bem legal para equipes mínimas.
Como se compara XP ao Scrum?
Acho que para desenvolver um sistema o que mais conta é a experiencia. Quanto mais eu desenvolvo mais eu aprendo, melhores meus sistemas ficam.
Tudo bem que trabalho sozinho, talvez esteja ai o motivo do meu sucesso, + eu creio que o grande problema de se desenvolver em grupo é a falta de experiencia, muitos acham que o que aprenderam na faculdade é o modelo ideal, e as vezes a experiencia te mostra que não é este o caminho.
Já programo a pelo menos uns 15 anos, e creio que a experiencia é o caminho do sucesso e de produtos de qualidade.
Dyego,
Belo texto. Porém, ficaria muito mais completo se ao final você falasse um pouco sobre cada metodologia ágil, sobretudo, sobre o Scrum que vem crescendo a passos largos no Brasil.
Grande abraço. Vou visitar seu site.
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.