A vocês que tem uma maior experiência de mercado TI …
Qual desses dois processos de desenvolvimento de software é o mais aplicável, seguro
ou que não gere tantas consequências ruins ao produto final? porque?
ps: Apresentarei um seminário sobre os processos ágeis e queria saber se essa metodologia
já é uma realidade nos processos de desenvolvimento, tendo em vista que a gente só aprende
a metodologia em cascata nas faculdades.
Abraços
Como tudo… depende.
Softwares onde os custos da release sejam muito altos e onde haverá pouca inclusão de novos requisitos depois de lançados - como softwares de prateleira, jogos ou firmwares - ainda podem se beneficiar processo em cascata. Não digo o waterfall clássico, onde existe uma única iteração, mas um ciclo com poucas iterações e de duração maior. Nesse caso, como o custo da release é alto, ele acaba pagando o overhead de papelada e burocracia desse processo. Um custo de release alto também representa um alto risco, o que justifica processos mais burocráticos. É lógico que mesmo nesse caso, não se deve abandonar algumas práticas atuais de desenvolvimento, mesmo que originalmente tenham sido aplicadas nos processos ágeis, como automação de builds ou testes.
No caso da absurda maioria de softwares, onde é fácil fazer build e distribuição, acho o processo ágil muito mais vantajoso. Por todas as razões apresentadas nos diversos artigos sobre esse tipo de processo: possibilidade de mudança de requisitos, eliminação do efeito “janela de lançamento” nos clientes (que faz com que peçam requisitos a mais com “medo” de perder uma oportunidade única de pedi-los), maior proximidade e comunicação com o cliente, mais transparência sobre o processo de desenvolvimento, entre outros.
[quote=ViniGodoy]Como tudo… depende.
Softwares onde os custos da release sejam muito altos e onde haverá pouca inclusão de novos requisitos depois de lançados - como softwares de prateleira, jogos ou firmwares - ainda podem se beneficiar processo em cascata. Não digo o waterfall clássico, onde existe uma única iteração, mas um ciclo com poucas iterações e de duração maior.[/quote]
Isso é non sense. Nenhum projeto que almege ter sucesso é em waterfall . E processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
Produtos de prateleira e jgoso beneficiam-se de constantes reviews de grupos de foco e atuam como forças para decidir o que fazer no proximo sprint.
Firmwares beneficiam-se de uma conversaão constantes entre as equipas de hardware e software permitindo uma evolução mais dinamica. Mesmo se pensarmos em firmware para uma máquina que já existe, podemos sempre pensar na subdivisão por features.
Watterfall não é recomendado nunca. É uma aberração que as pessoas o usem.
Tem que ter uma coisa em mente: nenhuma metodologia é bala de prata. Não existe e nunca vai existir uma receita que, se aplicada rigidamente, vai dar 100% certo.
O que vem acontecendo (eu pelo menos vejo isso, apesar de não estar no mercado corporativo a muito tempo) é que muita gente ainda não acredita em agile, apesar dos tantos cases de sucesso que existem por aí (vide globo.com, yahoo, thoughtworks e improve it). Eu sempre falei para o meu superior (que é tipo um gerente): se dá certo nessas empresas, que tem tamanhos diferenciados de equipes, porque não daria certo no nosso time? E aposto que muita gente fez isso… O que eu acho que acontece é que muita gente ainda tem a mentalidade fechada… Que isso não vai dar certo porque é simples ou coisa do tipo (geralmente porque seus projetos sempre deram certo (apesar das inúmeros horas extras que não foram pagas) e acham que não existe coisa mais certa do que pegar um requisito, escrever e entregar o produto final do cliente… pra ele chegar e falar: “ah, mas eu queria que fosse diferente”).
De qualquer forma, agile não é uma coisa pra você falar pra alguém que dá certo e pra essa pessoa tentar implantar. Agile é uma coisa pra ser colocada em prática, que exige atitude da pessoa que quer usar. Agile é matar a cobra e mostrar ela morta! Hehehe
Na minha opinião, o interessante é não usar Scrum ou Kanban ou uma metodologia já existente aí… Mas sim pegar as técnicas que existem dentro dessas metodologias e aplicar elas, pra ver o resultado. Deu certo, beleza, vamos continuar usando. Não deu certo? Vamos descobrir o porque de não ter dado certo e ver se foi nossa culpa ou se é algo que não fica bem adequada a nossa equipe.
Muitas pessoas podem citar várias empresas que adotaram agile e saíram do buraco. Como também existem histórias de pessoas que estavam usando algo mais “rígido” e estava dando certo. Aí foi e botou agile e a vida virou corrida e estressante.
Mas assim… eu não tenho o porte ainda pra falar se agile é um mar de rosas ou não. Nem pra falar se o waterfall é extremamente pifado e ruim. O que eu posso falar é o que venho lendo a uns 2, 3 anos… Tem muito conteúdo sobre isso. Tanto em empresas pequenas como grandes. Se você der uma procurada, tem um artigo da INFO (BLARGH!) que diz alguns empresas que usaram Scrum e deram certo.
waterfall?
é interessante ler o artigo original sobre o assunto:
O que se fala em “waterfall” é uma simplificação do primeiro exemplo desse paper. Eu usaria o nome de processos tradicionais, inspirados em fabrica (como linha de montagem/fordismo). E processos ágeis estamos falando de Crystal, Clear, Scrum, Kamban…
pacman,
Então vamos jogar a palavra ‘waterfal’ como aquela coisa de pegar os requisitos, ‘modelar’, escrever, testar e entregar e adeus. Isso que você falou de linha de fábrica seria mais ou menos assim: um engenheiro de requisitos pega os detalhes do sistema. O modelador, desenha os diagramas detalhadamente. O escrevedor escreve o código que tá nos diagramas. O testador testa e o motoboy entrega. Isso?
[quote=sergiotaborda]Isso é non sense. Nenhum projeto que almege ter sucesso é em waterfall . E processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
Produtos de prateleira e jgoso beneficiam-se de constantes reviews de grupos de foco e atuam como forças para decidir o que fazer no proximo sprint.
Firmwares beneficiam-se de uma conversaão constantes entre as equipas de hardware e software permitindo uma evolução mais dinamica. Mesmo se pensarmos em firmware para uma máquina que já existe, podemos sempre pensar na subdivisão por features.
Watterfall não é recomendado nunca. É uma aberração que as pessoas o usem.[/quote]
Ok Sérgio, então use a definição que o pacman deu. E eu concordo, waterfall puro é suicídio.
Acho que se vc resumir waterfall aos sistemas que são waterfall puro, não estaremos falando de nenhum processo hoje em dia.
É estranho ver autores como Philip Kruchten falarem algo sobre Waterfall(e derivados) e aqui ver algo totalmente abominável. Acho que vocês estão levando muito para o lado pessoal. Não adianta ficar propondo dissecações em algo que pode ser feito através de método X e/ou Y… ‘Com waterfall poderia fazer isso, mas também não daria para fazer aquilo, daí já não serve mais’ - simples, a escolha da metodologia não se dá por fungada para ver se vai servir, e sim pela alternativa que melhor satisfaça as necessidades, não?
Não dúvido da capacidade técnica de ninguém aqui, mas as vezes achos que certas pessoas se exaltam. Mas não é só por que o cliente ligou um dia e pediu algo novo que tivemos que re-lançar um novo programa objeto que estamos iterando e lançando os famosos releases.
Da mesma forma, tiro um exemplo simples, tenho que implementar um sistema de cálculo de previdência. É um modelo que existe em papel há 20 anos… onde eu vou usar as 6 ou 9 iterações? Cascatão na veia e lamba os beiços.
Dando prosseguimento, creio que a descrença no agile não parte dos técnicos, e sim dos administrativos. Tem sempre alguem querendo ver papel para justificar o gasto que TI está dando paro o negócio, já vi um caso desses de perto.
Olá
Quando e onde o Phillipe Kruchten defendeu isto? Tenho aqui na minha estante um livro dele de 2000 chamado The RUP, an introduction, 2nd Edition
O primeiro capítulo se chama Software Development Best Practices
Logo na página 4 ele aponta Symtoms and root causes of software development problems citando Caper Jones e Edward Yourdon. Várias das causas e sintomas são oriundos do waterfall de acordo com o que ele aponta.
Na página 6 ele condena o waterfall argumentando que este processo posterga o risco de modo que é custoso corrigir erros da fases anteriores (fases da figura dele: analysis, design, Code&Unit testing, Subsystem Testing, System testing). Na página seguinte tem a figura básica do livro dele baseada no modelo espiral de Barry Bohem com o título: An iterative and incremental process. Ele cita Tom Gilb que em 1988 escreveu:
“If you do not actively attack risks in your project, they will actively attack you”
A seguir o Phillipe escreve: “The waterfall approach tend to mask the real risks to a project until it is too late to do anything meaningful about them”
Então… mesmo em um livro sobre RUP, que para mim é burocratizado demais, o Kruchten defende processo iterativo. E isto em 2000.
É um absurdo que ainda existem faculdades como a da Naanda, com professores que ainda ensinam desenvolvimento de sistemas em cascata. Se o aluno pagou para aprender isto para mim é 171. Nenhum professor de uma área dinâmica como a de TI tem direito de estar mais de 10 anos atrasado.
Esta é a opinião de um velho de 65 anos que sempre se esforçou para me manter atualizado. Ser velho me dá o direito de lugar para sentar mas não me permite ficar tão desatualizado.
Naanda, faça um favor a você mesma. Esqueça rapidamente tudo o que este professor ensinou. E chame-o para se defender aqui e explicar porque em 2010 ainda ensina desenvolvimento em cascata.
[]s
Luca
Pois é, bastante complicado… o ensino de “Engenharia de Software” nas universidades ainda me parece ser muito baseado no waterfall, em analogias com Engenharia Civil e tudo mais…
com relacao ao RUP, as pessoas nao entendem muito bem o que de fato ele é (e acho que a IBM nao ajuda muito nisso). No ano passado no Encontro Agil, a palestra do Rodolpho Ugolini da IBM “Desamarrando o RUP” foi bastante esclarecedora (postei um resumo da palestra dele em http://alexandregazola.wordpress.com/2010/04/25/unveiling-the-rational-unified-process/ ). Em resumo, o RUP é um processo iterativo, guiado por casos de uso, onde praticamente tudo é opcional (ou seja, adapte e use o que for relevante para o projeto).
abracos
Além do artigo original, já citado, o vídeo do link http://alankelon.posterous.com/the-rise-and-fall-of-waterfall-0 é bastante instrutivo.
O RUP tem implementacao em fases, e por isso chamamos de processo incremental, nao iterativo. Iteratividade significa criar em cima de algo existente. No RUP o design oo (ou o modelo de dados, em alguns casos) é feito uma vez so, como uma cascata.
[quote=Alexandre Gazola]Pois é, bastante complicado… o ensino de “Engenharia de Software” nas universidades ainda me parece ser muito baseado no waterfall, em analogias com Engenharia Civil e tudo mais…
com relacao ao RUP, as pessoas nao entendem muito bem o que de fato ele é (e acho que a IBM nao ajuda muito nisso). No ano passado no Encontro Agil, a palestra do Rodolpho Ugolini da IBM “Desamarrando o RUP” foi bastante esclarecedora (postei um resumo da palestra dele em http://alexandregazola.wordpress.com/2010/04/25/unveiling-the-rational-unified-process/ ). Em resumo, o RUP é um processo iterativo, guiado por casos de uso, onde praticamente tudo é opcional (ou seja, adapte e use o que for relevante para o projeto).
abracos
[/quote]
As pessoas nao entendem o que é ser iterativo, quanto mais o que é RUP.
RUP tem uma fase para analise e outra para implementacao. Logo, se vc esta programando nao esta fazendo design iterativo, e sim seguindo uma especificação. Metodologias ageis sao iterativas.
E parece que temos mais um que não faz a mínima idéia.
Olha, existe um gráfico muito conhecido, que virou praticamente a marca registrada do RUP, até se você vir um livro com uma capa destas, sem nada escrito, vai falar “Olha, é o livro do RUP!”:
Este gráfico é tipico de qualquer metodologia iterativa, só mudando o tamanho, o momento de ínicio dessas disciplinas, e o quanto essas tarefas são paralelizadas, ou se acontecem juntas, emaranhadas uma a outra.
Eu acho muito estranho que tem milhares gerentes de projeto que tem audição seletiva. Se pegar num dicionário o significado de RUP, e ficar repetindo
“RUP é um processo iterativo de desenvolvimento de software”
“RUP é um processo iterativo de desenvolvimento de software”
“RUP é um processo iterativo de desenvolvimento de software”
eles ouvem
“RUP é um processo de desenvolvimento de software”
“RUP é um processo de desenvolvimento de software”
“RUP é um processo de desenvolvimento de software”
E sim, é um processo que tem uma carga bem pesada de artefatos gerados, mas bem na introdução fala para adaptar esse processo ao teu modo de trabalho, “aqui só damos sugestões, caso você precise delas, estão aqui prontas p/ usar 100%, ou só um pedaço”. A única coisa que não é opcional é ignorar a parte do “iterativo”.
Agora como isso virou o símbolo dos processos cascateiros, não faço a menor idéia.
Recomendo o livro do Craig Larmann, “Utilizando UML e padrões”, onde ele descreve em detalhes o uso do processo unificado, através de três iterações. O próprio autor é enfático em dizer que o prazo de uma iteração no RUP deve ser de 1 até 3 meses.
Como disse o Bruno, não sei de onde o pessoal tira a idéia de que o RUP é um processo em cascata. Foi por isso que iniciei a discussão falando em processos menos ágeis ou mais ágeis, porque o cascatão de apenas um ciclo já não existe há muito tempo.
Discutir cascata X processos ágeis é tão absurdo quanto discutir criacionismo X evolucionismo: o primeiro é somente baseado no folclore e na fé, e apenas o segundo, em argumentos racionais.
Não tenho tanto a acrescentar, confesso, mas gostaria de linkar um artigo interessante, como um filme da Pixar é feito (eu sei que não se trata de software, mas é válido). Na primeira olhada, dá impressão que é um processo em cascata, mas lembra bem mais o RUP, porque cada milestone é entregue um filme completo, ainda que esteja bem cru para ser exibido nas telonas.
Olá Luca, tudo bem?
Posso ter confundido os autores(também tenho o livro, mas na segunda versão, 2003), mas recentemente, em algum livro de abordagem a processos, metodologias e etc li a respeito do Cascata que, apesar de tudo, ainda é viável em projetos que possivelmente não serão alterados durante o ciclo de vida. Quando chegar em casa darei uma olhada em meus alfarrábios e verei se posso contribuir mais para a discussão.
[]'s
Quanto a situação da graduação da autora… acho que ela se expressou mal. Talvez a disciplina atual que ela cursa, toque principalmente na abordagem em cascata, até mesmo pelo fator histórico das cadeiras de ES. É impossível um professor, um cara que tem que guiar os futuros profissionais, só abordar esse processo… isso é ser anti-professor se a situação de fato é essa.
Olá
Infelizmente isto só acontece com aqueles trabalhinhos de escola que depois de prontos a gente nunca mais quer saber deles (nem sempre é o caso porque comecei a ganhar dinheiro com TI justamente com um trabalhinho da escola e usava o tal programinha em consultorias em 1971).
E concordo que um professor não deve abordar um só processo. Em 2010 ele tem a obrigação de citar a história, dizer que no milênio passado se usava desenvolvimento em cascata e apontar as suas falhas. É o que todos os livros fazem, a começar pelo livro que citei de 2000 e que cita outros grandes autores mais antigos que já condenavam a cascata.
Sei que deve ser dureza para um professor largar da novela e ler um livro mais novo do que o Tércio Pacitti onde ele aprendeu Fortran. Só que em informática nada dura mais do que 3 a 4 anos, quanto mais 10 ou mais anos.
[]s
Luca