[quote=luistiagos]waterfall?! ou seria waterfail?! ainda se usa isto?
[/quote]
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.
[quote=mochuara]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[/quote]
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?
Não, não se usa. Acho que em processo nenhum hoje em dia, sequer comenta-se sobre a possibilidade de waterfall.
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…
[quote=ViniGodoy]
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í.[/quote]
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.
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.
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.
[quote=ViniGodoy]
Agora, ter fases distintas != waterfall. O próprio XP tem fases distintas. [/quote]
Analise e implementacao em fases distintas == waterfall. Voce nao sabe nada de XP.
[quote=ViniGodoy]
Waterfall é a inexistência de ciclos. [/quote]
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.
[quote=ViniGodoy]
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.[/quote]
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”!
[quote=ViniGodoy]
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.[/quote]
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.
[quote=mochuara]
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”![/quote]
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.
Prezado Mochuara, tem base bibliográfica para suportar as afirmações do paragrafo citado acima?
[quote=ViniGodoy]
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. [/quote]
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).
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.
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.
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.
[quote=sergiotaborda]
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.[/quote]
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á
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á
[quote=ViniGodoy]
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.[/quote]
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
[quote=ViniGodoy]
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.[/quote]
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.
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.[/quote]
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.
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?
“O processo descrito no livro do larman é muito bom quando aplicado em equipes pequenas, de 1 ou 2 profissionais, onde problemas de comunicacao sao facilmente mitigados.” mochuara, 2010.
Tem certeza que são só essas duas referências? Eu te passei também o nome de um livro, de um autor renomado (que você casualmente ignorou).
A empresa que “vende UML” é, ninguém menos, que a IBM que, coincidentemente, também vende iteratividade.
Mas, se você ainda não está satisfeito, pode ler o livro do Philippe Kruchten. Aliás, pode olhar ali no look inside mesmo, onde ele diz como “best practice” número 1: “Develop software iteratively” (veja também na página 18, no capítulo The Rational Unified Process).
Então, eu pergunto. De que anos de experiência “de todos” você está falando? Por que, se você seguir a thread, vai ver que o Bruno e o rodrigoy, também reforçaram que o RUP é iterativo. O sergiotaborda, que foi o único que citou sobre um processo waterfall, não falou especificamente do RUP.
E, por mais tênues que tenham sido minhas referências anteriores, elas foram alguma referência. Sem falar nos meus “anos de experiência” de usuário de fórum, que também não deveriam ser ignorados… Busque no google “RUP is waterfall” ou “waterfall RUP”, e você vai achar um número irrisório de resultados. Busque “RUP is a iterative”, e você acha mais milhares de links.
Certo, empresas pequenas como a simples IBM, ou a minúscula Volvo, a pequena Intel, a pobre coitada da Visa ou a simplória British Airspace. Todas, certamente, tendo dentro equipes de “só” 1 ou 2 programadores.
[quote=Leonardo3001]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.
[/quote]
Desculpa galera, nao e minha intencao mudar o foco do topico, tanto que nao responderei mais a nenhuma dessas afirmacoes por aqui, mas nao pude deixar essa passar em branco…
Sou Criacionista, vindo do Evolucionismo (acreditem se quiser) e isso nao se passou atraves de uma experiencia milagrosa ou de fe, isso se deu por puro racionalismo.
Em 2000, em conflito com varios ramos em que a ciencia tomava em relacao ao evolucionismo, principalmente mais de 5 ou 6 teorias sobre um mesmo fossil, das quais nenhuma era comprovada e simplesmente deixada de lado, onde cada um acreditava na materia e teoria que quisesse, eu me deparei com um livro chamado “A Caixa Preta de Darwin” onde Michael Behe Bioquimico Norte Americano que aparece com a teoria do design inteligente e atraves de estudos bioquimicos desmente a Macro-Evolucao (vejam que nao duvido ainda da Microevolucao)… Sabe cara, corri atras de pessoas que desmentissem os estudo do cara e pouca coisa, mas muito pouca coisa foi achada e nenhuma de fato conclusiva, com ataques pessoais ao autor e sem fundamento ou experimento desmentindo…
Comecei a me perguntar porque e quando li sua afirmacao complementei o que eu ja imaginava. As pessoas sempre so procuram conhecer um dos lados da moeda, que alguem disse e foi tomado como verdade, e quando aparece alguem desmentindo e comprovando o contrario, da uma raiva saber que foi enganado por anos naquilo que se acreditava…
Ai realmente confiro que os processos podem mesmo ser comparados a Criacionismo X Evolucionismo, so resta saber quem eh quem, quem demora mais pra entregar o Produto e ja se atrasou muito, quem da mais custos e quem ate hoje nao conseguiu terminar seus estudos, sempre enganando o cliente, que coitado, acredita em tudo cegamente… hauhauahauhauahauahauahauahauhaua
So terminando, a Evolucao ate hoje ainda e uma teoria, ou seja, nao foi provada, o Elo Perdido nunca foi achado, embora todo Evolucionista diga que isso e questao de tempo (isso me lembra uma coisinha chamada FE)… E ainda tem mais, o Evolucionismo ainda e so mais uma teoria cientifica para o surgimento da vida, so e a mais famosa, mas nao e unanimidade…
Temos que sempre conhecer o outro lado da moeda pra criticar e evoluir nas coisas, sou doido pra trabalhar com Agil, queria ver como que e uma equipe agil, queria experimentar o processo e ganhar maturidade com ele, quem sabe um dia… No mais…
Abracos 
Concordo ctg. aliás eu queria ter dados essa referencia aqui mas não sabia o nome do livro nem do autor.
Hoje vivemos num tempo de dogmas igual ao da idade média. A diferença é nos dogmas , não no fato deles existirem.