Processo em cascata ou processos ágeis?

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

luistiagos wrote:waterfall?! ou seria waterfail?! ainda se usa isto?

Talvez nao no google, ou na apple. Mas pra maioria das empresas onde software nao seja essencial para seu negocio, processos waterfall (e waterfall-like como RUP), sao os mais previsiveis e faceis de se gerenciar.

This message was edited 4 times. Last update was at 16/06/2010 13:06:51

mochuara wrote:Assim como cara-palida? Estou falando de waterfall e agile, nao de empresas, e muito menos de experiencias especificas. Se a equipe é incompetente é uma outra discussao mas porque a impressao de que estou cacando culpados, ou ainda, descarregando frustacao? só estou esclarecendo pra vc como waterfall é diferente de agile, sem entrar no merito se metodologia X é boa ou ruim, é tao dificil pra vc discutir sem achar existe um complô da casa branca contra o RUP?

E a menos que haja uma nova definicao de RUP onde os requisitos sao especificados em testes executaveis por exemplo, o design definido no proprio codigo e nao em diagramas e documentos (que depois vao ser interpretados por digitadores de codigo), nao consigo ver RUP como sendo iterativo

A impressão existe porque você está falando de um processo que não é o RUP. Por exemplo, você insiste em dizer que ele é waterfall, quando um dos pilares do processo é o desenvolvimento iterativo. É como se alguém aparecesse aqui no fórum de repente, afirmando que XP não funciona pq é waterfall. Obviamente o cara estaria errado, e você perguntaria de onde ele tirou aquela noção maluca. Aí você vai lá, cita referências bibliográficas, pede para ele conferir. E ele volta, com força total, dizendo que o processo é sim waterfall, desprezando todo material que você citou.

Então, das duas uma:
a) Ou você tem completo desconhecimento sobre o RUP atualmente, pois está citando o processo como era em 1999 (e, mesmo naquela época, ele já não era waterfall, embora fosse mais bucrático e exigisse mais documentação em papel).
b) Ou você vivenciou alguma experiencia traumática como a que falei, o que não seria de se surpreender com as empresas que tem por aí.
c) Ou você é um troller

Eu descarto a alternativa c, pois não se aplica ao seu caso.

Então, eu pergunto, de onde vem o seu conhecimento sobre o RUP? Ou esteve em uma empresa que o utilizasse efetivamente? E por que você insiste em falar que ele é waterfall, quando qualquer material que você busque sobre o assunto diz ao contrário? Você pode citar uma única fonte sequer, que diga que ele é waterfall?

luistiagos wrote:waterfall?! ou seria waterfail?! ainda se usa isto?

Não, não se usa. Acho que em processo nenhum hoje em dia, sequer comenta-se sobre a possibilidade de waterfall.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:Ou você tem completo desconhecimento sobre o RUP atualmente, pois está citando o processo como era em 1999 (e, mesmo naquela época, ele já não era waterfall, embora fosse mais bucrático e exigisse mais documentação em papel).

Interessante a afirmacao que RUP era waterfall, depois se converteu, é isso?

Corresponde com a minha visao, mas nela o movimento para dar mais agilidade ao RUP fracassou, em parte por causa disso que falei, RUP é baseado no modelo de linha de producao, onde temos fases de analise e implementacao claramente distintas, e nao um processo iterativo, baseado em feedback ageis. Agora se existe outra escala de iteratividade, ou se ela tem que vir em pares com icremental (assim como pessoas frias e calculistas, sabe?), é outra historia...

ViniGodoy wrote:
Ou você vivenciou alguma experiencia traumática como a que falei, o que não seria de se surpreender com as empresas que tem por aí.

Na visao de um programador de software qual seria essa "experiencia traumatica"? Nao gostar do emprego e nao poder pedir demissao? Qual o drama?

Penso que, como profissional, nao devemos defender processos como vendedores de biblias, ou podemos cometer equivocos que podem ser igual traumaticos. Concordo que waterfall é um assunto polemico e muitos programadores tem aversao ao termo, mas vamos ser realistas. A maioria dos projetos fracassam por falta de pessoas capacitadas para a tarefa, e nao porque metodolgia X é ruim ou o processo Y é waterfall.

mochuara wrote:Interessante a afirmacao que RUP era waterfall, depois se converteu, é isso?

Não estava me referindo ao waterfall, mas a parte sobre ter menos comunicação entre os membros da equipe. Esse foi um ponto que o RUP melhorou muito nos últimos anos. Tanto que deixei claro que minha observação não se referia ao waterfall.

E você também não citou uma única fonte ou referência sobre RUP ser waterfall.

Agora, ter fases distintas != waterfall. O próprio XP tem fases distintas.
Waterfall é a inexistência de ciclos.

Agora, você tocou num ponto chave. Como eu já citei, o RUP não se vende como um processo ágil, por isso a distinção é clara. Ele é iterativo, existe sim mais papéis e mais documentação, e ele não é ágil. O volume de papelada também reduziu consideralvelmente nos últimos 10 anos.

Antes, recomendava-se uma grande extensão de diagramas UML. Hoje, recomenda-se documentar apenas os pontos chaves do sistema, para dar uma representação visual e clara do que está sendo programado.

mochuara wrote:Penso que, como profissional, nao devemos defender processos como vendedores de biblias, ou podemos cometer equivocos que podem ser igual traumaticos.

Eu concordo com você. Inclusive, não uso o RUP e sim o SCRUM, e até prefiro. Mas acho também que não podemos é falar do processo algo que ele não é.
Eu não estava defendendo o RUP: aliás, é uma mania em discussões como essa as pessoas acharem que estamos "defendendo" coisas, ou "agredindo" outras. Não é nada disso. Estava esclarecendo com o processo funciona. E ele não era nem próximo da visão waterfall de 1960 para desenvolvimento em mainframes que você descrevia.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:
Agora, ter fases distintas != waterfall. O próprio XP tem fases distintas.

Analise e implementacao em fases distintas == waterfall. Voce nao sabe nada de XP.

ViniGodoy wrote:
Waterfall é a inexistência de ciclos.

Como falei, waterfall é uma metafora. Uma empresa nao fica ligada 24/7, mas isso tb nao importa. Qual imbecil se prenderia a uma metafora? Se vc tem experiencia em RUP sabe que analistas nao obtem feedback dos programadores sobre problemas ocorridos durante a implementacao, nao como oportunidades de melhoria, apenas como bugs, isso por si so é uma grande diferenca de perspectiva na minha opiniao.

ViniGodoy wrote:
Antes, recomendava-se uma grande extensão de diagramas UML. Hoje, recomenda-se documentar apenas os pontos chaves do sistema, para dar uma representação visual e clara do que está sendo programado.

Sim, é engracado ouvir gente falando que RUP é iterativo. A agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis, mas por outro lado aumentou a pressao da equipe de desenvolvimento que vai ter que descobrir que raios deve fazer algum parte do sistema que nao é "chave"!

ViniGodoy wrote:
Eu concordo com você. Inclusive, não uso o RUP e sim o SCRUM, e até prefiro. Mas acho também que não podemos é falar do processo algo que ele não é.
Eu não estava defendendo o RUP: aliás, é uma mania em discussões como essa as pessoas acharem que estamos "defendendo" coisas, ou "agredindo" outras. Não é nada disso. Estava esclarecendo com o processo funciona. E ele não era nem próximo da visão waterfall de 1960 para desenvolvimento em mainframes que você descrevia.

Voce chegou a dizer que um projeto pode suceder ou fracassar apenas trocando de waterfall para RUP. A ironia é que vc nao sabia que um é fortemente influenciado pelo outro.

mochuara wrote:
Sim, é engracado ouvir gente falando que RUP é iterativo. A agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis, mas por outro lado aumentou a pressao da equipe de desenvolvimento que vai ter que descobrir que raios deve fazer algum parte do sistema que nao é "chave"!

O RUP nunca foi waterfall. Não é waterfall. Se você acha engraçado gente falando que o RUP é iterativo, pode rir agora:

O RUP é iterativo. Sempre foi. E é um processo customizável, então, se a "agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis", então o RUP é Ágil desde 1998.

http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/

Prezado Mochuara, tem base bibliográfica para suportar as afirmações do paragrafo citado acima?

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:
Agora, você tocou num ponto chave. Como eu já citei, o RUP não se vende como um processo ágil, por isso a distinção é clara. Ele é iterativo, existe sim mais papéis e mais documentação, e ele não é ágil. O volume de papelada também reduziu consideralvelmente nos últimos 10 anos.

A distincao esta longe de ser clara, como pode notar pela sua dificuldade em diferenciar o mindset agile iterativo (XP), e o tradicional waterfall baseado em linhas de producao (RUP).

mochuara wrote:Sim, é engracado ouvir gente falando que RUP é iterativo. A agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis, mas por outro lado aumentou a pressao da equipe de desenvolvimento que vai ter que descobrir que raios deve fazer algum parte do sistema que nao é "chave"!

Como assim "por outro lado aumentou a pressão da equipe"? O que eu quis dizer, é que não se perde tempo diagramando interações óbvias do sistema. Há alguma dúvida sobre como seja o caso de uso de "usuário preenche formulário de fale conosco"? Há mesmo necessidade de fazer um diagrama com um bonequinho de um lado e uma elipse do outro? Obviamente que não. Por isso, não se faz esse diagrama.

mochuara wrote:Como falei, waterfall é uma metafora. Uma empresa nao fica ligada 24/7, mas isso tb nao importa. Qual imbecil se prenderia a uma metafora? Se vc tem experiencia em RUP sabe que analistas nao obtem feedback dos programadores sobre problemas ocorridos durante a implementacao, nao como oportunidades de melhoria, apenas como bugs, isso por si so é uma grande diferenca de perspectiva na minha opiniao.

Não sei de onde você tirou que um feedback de um programador no RUP é considerado um bug. Pode dar uma única citação de algum material que diga isso? Antes de você continuar falando bobagem, eu recomendo fortemente que você leia o livro do Larman, ou pelo menos que ache alguém importante, de onde você esteja tirando tanta baboseira.

Analista idiotas não ouvem programadores. O processo é bem claro ao dizer que deve haver feedback. Aliás, ele também estimula que as duas equipes trabalhem colaborativamente.

ViniGodoy wrote:Voce chegou a dizer que um projeto pode suceder ou fracassar apenas trocando de waterfall para RUP. A ironia é que vc nao sabia que um é fortemente influenciado pelo outro.

Disse? Pode fazer o quote?
Há poucas chances de um processo ser bem sucedido se for waterfall. O modelo foi abandonado há vários anos, e não foi à toa.

Se for RUP, há chances de sucesso, certamente, pois é um processo iterativo. Mas, processo nenhum, nem RUP, nem XP, nem Scrum garantem o sucesso de um projeto. Contribuem, mas não garantem.
Eu não me atreveria em comparar o RUP com o XP ou Scrum. Acho que cada um tem o seu papel.

sergiotaborda wrote:
Vc precisa aprender os fatos antes de poder fazer esses comentários. Scrum nasceu do Lean criado pela toyota e não do XP. O XP nasceu do lean aplicado a desenvolvimento ( o scrum é aplicado a gestão). Ou seja, agil não nasceu no meio universitário. Nasceu da filosofia oriental numa fábrica de carros.

Scrum não veio do Lean. Apesar disso ser uma crença popular em desenvolvimento de software, não há fundamento para acreditar em tal. XP também não nasceu do Lean. Agil não nasceu numa fábrica de carro. Nenhum dos proponentes do Agile eram operários. Não há razão para acreditar em tal....

This message was edited 1 time. Last update was at 16/06/2010 23:35:07

rodrigoy wrote:Scrum não veio do Lean. Apesar disso ser uma crença popular em desenvolvimento de software, não há fundamento para acreditar em tal. XP também não nasceu do Lean. Agil não nasceu numa fábrica de carro. Nenhum dos proponentes do Agile eram operários. Não há razão para acreditar em tal....

E esse artigo aqui?
http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

Ele é apontado como um dos pais do Scrum. Foi publicado pela Harvard Business School, por funcionários da Toyota.

Olá

rodrigoy wrote:Scrum não veio do Lean.

Esta confusão realmente não tem razão de existir pelo fato de Scrum ser um processo empírico ao contrário de Lean e Kanban que são processos oriundos de chão de fábrica e não empíricos.

Recentemente o Ken Schwaber blogou sobre isto em http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

A menos que o Sérgio esteja se referindo que Lean já existia antes do Scrum. Mas neste raciocínio seria melhor dizer que Scrum veio do Waterfall, isto é, Scrum surgiu justamente devido a insatisfação com o Waterfall.

Uma coisa que não disse nas minhas respostas anteriores é que waterfall pode ser usado em um projeto com sucesso sob o ponto de vista estrito do sistema atender ao que se propôs. Mas quando a gente lembra do que o Kruchten dizia em 2000 sobre riscos com waterfall, pelo menos fica a impressão de que com waterfall as chances do sucesso acontecer são menores.

Reparem que só defini sucesso como atendimento aos requisitos de uso. Quando se consideram custos e prazos os riscos de insucesso aumentam.

[]s
Luca

Olá

ViniGodoy wrote:
E esse artigo aqui?
http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

Ele é apontado como um dos pais do Scrum. Foi publicado pela Harvard Business School, por funcionários da Toyota.

O Scrum nasceu no início dos anos 90 e é um filho desnaturado sem mãe. Tem só 2 pais: Ken Schwaber e Jeff Sutherland.

Se eles tiveram outras influências, a maior delas foi a insatisfação com o que existia antes. É claro que a formação deles incluia tudo que aprenderam mas não lembro de créditos a outras pessoas (nos textos do Schwaber).

[]s
Luca

ViniGodoy wrote:
E esse artigo aqui?
http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

Ele é apontado como um dos pais do Scrum. Foi publicado pela Harvard Business School, por funcionários da Toyota.

Nonaka e Takeuchi? Na Toyota? Tem certeza? Sempre achei que eles eram professores na Universidade Hitotsubashi.

Duvido muito que o processo seja usado "ipsis literis" para software, independente da sua origem. Ser da Toyota ou não é irrelevante, o que importa é como é aplicado em software hoje.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:

mochuara wrote:Sim, é engracado ouvir gente falando que RUP é iterativo. A agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis, mas por outro lado aumentou a pressao da equipe de desenvolvimento que vai ter que descobrir que raios deve fazer algum parte do sistema que nao é "chave"!

Como assim "por outro lado aumentou a pressão da equipe"? O que eu quis dizer, é que não se perde tempo diagramando interações óbvias do sistema. Há alguma dúvida sobre como seja o caso de uso de "usuário preenche formulário de fale conosco"? Há mesmo necessidade de fazer um diagrama com um bonequinho de um lado e uma elipse do outro? Obviamente que não. Por isso, não se faz esse diagrama.

Acho que vc nao entendeu nada mesmo. Nao é um problema de modelagem, mas de comunicacao. As ferramentas atuais nao sao capazes de gerar modelos e comunicar eficientemente, ou seja, sem que haja perda de informacoes relevantes, entre as equipes de analise e implementacao.

No mais, nao é dificil perceber que um processo que assume que todo formulario de fale conosco vai ser obvio, nao tem nada de iterativo. Mas repito, sao caracteristicas diferentes, nao quer dizer que um é melhor que outro. Portanto nao quero que ninguem se sinta ofendido em saber que pratica waterfall development.

ViniGodoy wrote:

mochuara wrote:Como falei, waterfall é uma metafora. Uma empresa nao fica ligada 24/7, mas isso tb nao importa. Qual imbecil se prenderia a uma metafora? Se vc tem experiencia em RUP sabe que analistas nao obtem feedback dos programadores sobre problemas ocorridos durante a implementacao, nao como oportunidades de melhoria, apenas como bugs, isso por si so é uma grande diferenca de perspectiva na minha opiniao.

Não sei de onde você tirou que um feedback de um programador no RUP é considerado um bug. Pode dar uma única citação de algum material que diga isso? Antes de você continuar falando bobagem, eu recomendo fortemente que você leia o livro do Larman, ou pelo menos que ache alguém importante, de onde você esteja tirando tanta baboseira.

Porque eu iria ignorar anos de experiencia somados por todos daqui do forum por uma citação no site da empresa que vende ferramentas UML ou em um blog de nerd?

Notícias, artigos e o maior fórum brasileiro sobre Java