EU diria que o RUP está para o SCRUM como o Java está para o PHP.
[quote=Andre Brito]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.
[/quote]
Isso é uma grande desculpa para os medíocres. Numa escala relativa de qualidade aquele que estiver na frente sim é a bala de prata. Ou seja, sim é aquele que deve ser usado por todo o mundo. Não me venham com essas de que cada metodologia serve uma proposito diferente que isso é balela. todas devem servir um unico proposito : fazer software.
Agil é melhor que rup que é melhor que waterfall. Isto é indiscutivel e existem N estudos em montes de livros por ai. basta saber ler.
A diferença é que Agil atua na forma de pensar, é um paradigma, e isso influencia tudo desde o que o programador escreve até ao contrato firmado com o cliente. Todas as partes têm que ser apoiadas no mesmo paradigma. se não for assim, não é agil.
O que assistimos hoje é a conjunto de hibridos malucos e esse que é o problema. O cara usa metada do paradigma e depois fala que não funciona. É como usar mal o hibernate e dizer que ele é porcaria.
Agil é o próximo futuro. Pode existir algo melhor depois disso, claro, mas por agora, neste momento, o melhor objetivo possivel é implantar Agil.
Quem ainda duvida disto não sabe o mundo em que vive.
[quote=mochuara][quote=sergiotaborda]
processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
[/quote]
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]
É exatamente ao contrário. Iterativo significa refinar com o tempo, incremental significa basear-se em algo pre-existente. (referencia)
Um processo agil usa os dois.
Creio que para um gerente de projeto tradicional, “iterativo” aqui nao agrega muita coisa, sendo automaticamente filtrado da sentenca sem causar qualquer prejuizo a sua compreensao. Mas não é porque vc colocou waterfall dentro de um laco for, que vc tem iteratividade no mesmo sentido de metodologias ageis. Iteratividade em metodologias ageis significa fazer design no momento em que codifica. Portanto, pelo bem do significado de iteratividade…
Repita comigo, RUP não é um processo iterativo.
[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]
Em RUP o milestone nao gera um “filme completo”, e sim um artefato, definido como objetivo para aquela fase.
[quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
[/quote]
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]
É exatamente ao contrário. Iterativo significa refinar com o tempo, incremental significa basear-se em algo pre-existente. (referencia)
Um processo agil usa os dois.
[/quote]
Contrario de quem? É exatamente isso. Criar em cima de algo existente é requisito basico para refinar algo com o tempo, ou seja, iteratividade.
Mas no RUP nao ha design iterativo, apenas incremental.
Como pode ver na imagem acima, criacao e construcao nao estao sobrepostos no tempo.
O Processo Unificado foi elaborado por quem entende de Análise e Projeto de Software. Na verdade por quem construi tudo o que voce entende por isso. São eles Ivar Jacobson, Grady Booch e James Rumbaugh. A Metologia Àgil surgiu primariamente no meio universitário, visto o XP, por digitadores de algoritmos (universitarios) e sua simplicidade visceral inspirou gente do mercado como Ken Schwaber do SCRUM que une o melhor dos dois: a filosofia KISS do XP e alguns dos formalismos metódicos e eficazes do PU.
Há muito gente escrevendo sobre Metodologias Àgeis, é uma ladinha sem fim, um blá blá blá. A grande maioria são textos enfadonhos pouco objetivos e concisos e recheados de erros técnicos e total desconhecimento sobre Engenharia de Software. Acho que essas pessoas não deveriam estar na área de exatas, e sim na humanas, por que parece que gostam de escrever para se por a vista.
[quote=mochuara]
Contrario de quem? É exatamente isso. Criar em cima de algo existente é requisito basico para refinar algo com o tempo, ou seja, iteratividade.
Mas no RUP nao ha design iterativo, apenas incremental.
Como pode ver na imagem acima, criacao e construcao nao estao sobrepostos no tempo.[/quote]
Mochuara, parece que voce tem dificuldade em interpretar gráficos. Qual foi sua nota no ENEM?
Estou mostrando uma analogia, a Pixar não é uma empresa de software (apesar de usá-la para apoio).
O artefato deve ser entendido como uma abstração pra qualquer coisa, inclusive software executável. O artefato deve ser algo tangível para o cliente.
Fazer design enquanto se codifica não é definição de iteratividade. Acho que nunca foi e nunca vai ser. Por que isso não tem absolutamente nada a ver com iteratividade.
Você pode fazer design enquanto codifica num único e grande ciclo, sem rever um único requisito sequer, falando com o cliente uma única vez, e você terá um processo em cascata e um sistema extremamente mal implementado.
Iteratividade está no fato de re-analisar e modificar o que já foi feito. E isso pode ser feito com intervalos de sprint maiores ou menores, com a geração de mais ou menos documentação, com fases de análise e implementação separadas ou não.
Se você realmente repete isso, está se convencendo de uma mentira. Você pode dizer que RUP não é um processo ágil, e isso ele não alega ser, mas não que ele não é um processo iterativo.
Estou mostrando uma analogia, a Pixar não é uma empresa de software (apesar de usá-la para apoio).
O artefato deve ser entendido como uma abstração pra qualquer coisa, inclusive software executável. O artefato deve ser algo tangível para o cliente.
[/quote]
Entendi que era uma analogia, nao tinha entendido que “filme completo” podia ser qq coisa. Podia ter falado que era um trailer.
Fiz uma intervenção bem fffffuuuu sobre como seria a passagem do tempo numa metodologia RUP.
Cada fase tem análise de negócio, análise/modelagem, implementação, teste e deployment; se repetindo a cada entrega de artefato.
oi,
na hora de vender um projeto o cliente quer um escopo, um cronograma e um custo
como aplicar ágil tendo um escopo fixo?
na minha opinião isso é impossível
ou seja, a mudança teria que partir do cliente, que passa a contratar o desenvolvimento do sistema como um serviço e não como um produto…
abs
Acho que você fez uma simplificação grosseira. Primeiro, porque existem vários tipos de software. Segundo, porque existem várias situações diferentes de deploy, com custos diferenciados em cada uma.
Antes de adotar um processo mais ou menos burocrático é preciso entender para que a burocracia serve. A burocracia tenta evitar erros antes da primeira unidade do software ir para produção. Se seus custos de produção são baixos, como no caso de aplicações que rodam num servidor web, você pode ter muito pouca burocracia, pois um erro não será um grande problema. Ele é facilmente identificado e corrigido. É um princípio das metodologias ágeis que o custo de modificação do software não é mais tão alto quanto era antigamente.
Mas será que esse princípio vale para todo software? Considere um firmware de um hardware que você mesmo está produzindo. Considere que esse hardware é especialista, e que seu cliente não irá “meter a mão” nele, e atualiza-lo ele mesmo. Aliás, pense que seu hardware não estará ligado à internet. Um erro ali, pode representar a atualização de dezenas de placas no mercado, envolvendo deslocamento de equipes de campo. Não existe a opção de “iteratividade” após determinado momento do sistema. Se algum erro grave passar dali, você terá um prejuízo avaliado em milhões. Aposto que, antes desse momento, você estará respaudado por muita bucracria.
A burocracia não precisa necessariamente ser diagramas UML. Pode ser, por exemplo, relatórios de testes, relatórios de cobertura, documentações de trechos críticos de software e demais coisas que mantenham o software funcionando a longo prazo. Mas você não poderá simplesmente rodar o teste na sua máquina, pois a empresa exigirá garantias de que tudo foi executado corretamente, completamente, e aí entrará documentos de revisão.
Logicamente, você poderá ter ciclos menores antes da liberação do release final, inclusive, até adotar práticas ágeis nesse processo. Mas, entender as situações de deploy caro, ajuda-nos a entender porque existem metologias tão burocráticas em primeiro lugar. E ajuda-nos a entender como os ciclos pouco iterativos foram concebidos: É só lembrar que na época que as primeiras metodologias surgiram, era caro fazer uma compilação dentro do próprio ambiente da equipe de desenvolvimento - e não é à toa que testes de mesa eram um processo comum em praticamente toda metodologia.
E também ajuda a perceber porque para a grande maioria dos softwares hoje, não é necessário a existências de ciclos tão grandes ou burocráticos. É fácil atualizar software, é barato corrigir erros, e é melhor entregar algo pequeno e errado para o cliente, e deixar que ele peça a modificação daquilo, do que tentar se precaver e entregar ao grande e impossível de se modificar depois.
Fazer design enquanto se codifica não é definição de iteratividade. Acho que nunca foi e nunca vai ser. Por que isso não tem absolutamente nada a ver com iteratividade. [/quote]
Mas distingue entre waterfall e agile. 
[quote=ViniGodoy]
Você pode fazer design enquanto codifica num único e grande ciclo, sem rever um único requisito sequer, falando com o cliente uma única vez, e você terá um processo em cascata e um sistema extremamente mal implementado. [/quote]
Nao é o periodo ou numero de iteracoes ou fases que diferenciam as metodologias. Leia o posto do pacman la atras que ele explica melhor esse ponto. Mas concordo com vc, apesar de achar bem improvavel que alguem precise fazer isso. Se quer fazer waterfall usa RUP.
[quote=ViniGodoy]
Iteratividade está no fato de re-analisar e modificar o que já foi feito.[/quote]
Isso é o mesmo que dizer que pra correr uma maratona vc precisa colocar uma perna na frente da outra.
[quote=Leonardo3001]@Mochuara
Fiz uma intervenção bem fffffuuuu sobre como seria a passagem do tempo numa metodologia RUP.
Cada fase tem análise de negócio, análise/modelagem, implementação, teste e deployment; se repetindo a cada entrega de artefato.
[/quote]
Olha, se vc tiver muita sorte, software executavel so sai na fase de construcao.
[quote=André Fonseca]oi,
na hora de vender um projeto o cliente quer um escopo, um cronograma e um custo
como aplicar ágil tendo um escopo fixo?
na minha opinião isso é impossível
ou seja, a mudança teria que partir do cliente, que passa a contratar o desenvolvimento do sistema como um serviço e não como um produto…
abs[/quote]
Nao tendo escopo fixo, outra forma de pensar e ter usuarios ao inves de clientes, porque usuarios nao se importam como algo foi construido.
No que distingue? Você pode ter equipes ágeis que fazem análise antes de codificar, ainda que dentro da micro-tarefa que foram assinaladas. Não é a toa que processos como o PSP estão sendo usados com sucesso por equipes ágeis.
Não é só isso que define uma metodologia como ágil ou não. Ou mesmo entre uma metodologia e outra.
Mas isso distingue ela como “waterfall” ou “iterativa”. Pois essa definição é diretamente associada a presença ou não de ciclos.
Não existe “metodologia” waterfall. Waterfall está em decidir se você vai ou não repetir seu ciclo de desenvolvimento. Hoje, a palavra está associada em repetir com pouca freqüência.
[quote=mochuara][quote=Leonardo3001]@Mochuara
Fiz uma intervenção bem fffffuuuu sobre como seria a passagem do tempo numa metodologia RUP.
Cada fase tem análise de negócio, análise/modelagem, implementação, teste e deployment; se repetindo a cada entrega de artefato.
[/quote]
Olha, se vc tiver muita sorte, software executavel so sai na fase de construcao.[/quote]
Ah tá! E como você nunca viu macaco virar gente, logo você conclui que evolução não existe.
É possível sim ter software pronto na fase de Inception. É você que não viu isso.
No que distingue? Você pode ter equipes ágeis que fazem análise antes de codificar, ainda que dentro da micro-tarefa que foram assinaladas.[/quote]
Se é uma microtarefa como pode haver fases distintas para analise e codificacao. Voce esta contando com microfases, nanofases, e assim sucessivamente?
Voce deve estar se referindo ao ciclo red-green-refactor do XP, mas precisa reconhecer que a comparacao e totalmente fora de contexto.
[quote=ViniGodoy]
Não existe “metodologia” waterfall.[/quote]
hehe, mataram a coitada.