Arquivo Discussoes de Programacao e Tecnologia 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.
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.
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?
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.
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.
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
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
EU diria que o RUP está para o SCRUM como o Java está para o PHP.
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.
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.
processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
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.
É 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.
processo com mais de uma iteração não são waterfall (por definição de waterfall - a agua não cai duas vezes).
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.
É 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.
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.
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.
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.
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.
Mas distingue entre waterfall e agile. 
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.
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.
Iteratividade está no fato de re-analisar e modificar o que já foi feito.
Isso é o mesmo que dizer que pra correr uma maratona vc precisa colocar uma perna na frente da outra.
@MochuaraFiz 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.
Olha, se vc tiver muita sorte, software executavel so sai na fase de construcao.
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
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.
@MochuaraFiz 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.
Olha, se vc tiver muita sorte, software executavel so sai na fase de construcao.
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.
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.
Não existe “metodologia” waterfall.
hehe, mataram a coitada.
Olá
Cite as fontes desta afirmação ou prove. E o monte de bons autores que existiram antes e depois deles? Estes 3 ficaram famosos juntos por terem se reunido e unificado algumas das metodologias existentes. E por terem criado a UML (método de Booch, OOSE do Jacobson e OMT do Rumbaugh, deixaram de fora as metodologias Fusion, Shlaer-Mellor e Coad-Yourdon cujos autores não se juntaram ao Booch na Rational). Muito mais gente se juntou ou influenciou o grupo dos 3 na criação da UML incluindo gente famosíssima como Peter Coad, Ward Cunningham (do manifesto ágil e dos CRC cards junto com o Kent Beck), Eric Gamma (gang of four, JUnit, Eclipse), Ralph Johnson (gang of four), Phillipe Kruchten, Bob Martin (manifesto ágil), Bertrand Meyer, Rebecca Wirfs-Brock (impossível ignorá-la), Edward Yourdon, Jeff Sutherland (co-criador do SCRUM) e outros.
Até hoje gosto dos CRC cards do Cunningham & Beck para descobrir as classes do sistema.
Aqui não vou pedir para provar porque TODO mundo sabe quem é o Kent Beck, criador do XP, realmente um digitador de algoritmo (o mais famoso deles é o JUnit).
Recomendo a todos que quiserem falar da história do desenvolvimento de sistemas que antes de qualquer coisa, visitem um site chamado google.com
E já está mais do que na hora de sumirem com o termop engenharia de software. Desenvolvimento de software é desenvolvimento de software. Que arranjem um nome específico para isto como existia antigamente o termo analista de sistemas (muito melhor do que engenheiro de software). Como engenheiro, ser racional, cartesiano, acostumado a trabalhar com fórmulas e métodos determinísticos, nunca vi nenhuma semelhança entre as atividades de um engenheiro com às de um criador de software que manipula grandezas empíricas. Para mim o termo engenheiro de software, apesar de consagrado, não representa nada do que já fiz na vida desenvolvendo sistemas.[]s
Luca
hehe, mataram a coitada.[/quote]
Existem metodologias que seguem o modelo waterfall, assim como existem metodologias que seguem o modelo iterativo. Waterfall é um modelo de desenvolvimento, não uma metodologia.
Isso porque waterfall não define um conjunto de processos, como uma metodologia definiria.
@MochuaraFiz 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.
Olha, se vc tiver muita sorte, software executavel so sai na fase de construcao.
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.
Se vc nao ve a evolucao, ela nao existe.
Luca, o modelo unificado foi proposto pela primeira vez no livro The Unified Software Development Process, de 1999, escrito por Ivar Jacobson, Grady Booch e James Rumbaugh.
Olá
Foi do livro que acompanha este, isto é, The UML user guide de abril/99 que tirei o que escrevi. Mas nem precisava ter escrito tudo que escrevi. Acho que fica claro no U do UML que foi um processo de unificação do que já existia antes.
[]s
Luca
OláFoi do livro que acompanha este, isto é, The UML user guide de abril/99 que tirei o que escrevi. Mas nem precisava ter escrito tudo que escrevi. Acho que fica claro no U do UML que foi um processo de unificação do que já existia antes.
[]s
Luca
Sim, com certeza. Eu comecei a estudar pelo livro do Grady Booch, que já definia uma metodologia própria. A idéia por trás da UML foi acabar com a “metodology war” que existia na época da estruturada, e que estava começando a surgir na OO. Você deve estar lembrado… uns adotavam Chris Gane, outros o próprio Booch… era uma bagunça.
Aí os metodologistas viram que era mais fácil (e lucrativo também), se juntar e fazer uma proposta só. E claro, abrir com isso uma consultoria, chamada Rational, para vender essa mesma consultoria.
Existem metodologias que seguem o modelo waterfall, assim como existem metodologias que seguem o modelo iterativo. Waterfall é um modelo de desenvolvimento, não uma metodologia.Isso porque waterfall não define um conjunto de processos, como uma metodologia definiria.
RUP define modelagem e implementacao como fases separadas, isso é caracteristica de processo (ou seja la como vc chama) waterfall.
Todos aqui sabem que se vc precisa esperar a fase de implementacao para saber que o design existente em casos de uso e lindos diagramas UML funciona, entao nao ha avanco em termos de design do software num ritmo suficiente para chamarmos de iteratividade.
E o fato de RUP ser waterfall nao é algo necessariamente ruim. Waterfall é praticamente institucionalizada nas fabricas de software e empresas em geral, com exceçao de algumas consultorias mais descoladas que usam agile. Ou seja, existem muitas oportunidades para o profissional RUP no mercado!
Mochuara, quanto tempo você acha que dura cada fase daquelas? Os tempos são em torno de 1 semana, no máximo. Num ciclo RUP tradicional, você teria o ciclo completo em menos de um mês. É um ritmo próximo de algumas equipes Scrum.
Rup não é waterfall.
Referências:
http://www-01.ibm.com/software/awdtools/rup/
Acho que você claramente confunde desenvolvimento iterativo com desenvolvimento ágil.
Iteratividade é o primeiro princípio básico do RUP. Então, você está falando de um processo que você claramente não conhece.
Mochuara, quanto tempo você acha que dura cada fase daquelas? Os tempos são em torno de 1 semana, no máximo. Num ciclo RUP tradicional, você teria o ciclo completo em menos de um mês. É um ritmo próximo de algumas equipes Scrum.
Principalmente se nao houver aquelas reunioes matinais que sao um saco. Mas pelo menos a equipe como um todo colabora para analise e implementacao no SCUM. Nao substime o esforco necessario para fazer isso acontecer no RUP e em processos waterfall em geral, que possuem equipes diferentes para analise e implementacao e portanto precisam transferir esse conhecimento, geralmente por meio de modelos intermediarios extremamente ineficientes.
Aparentemente você teve uma péssima experiência pessoal em algum time que não usava o RUP, mas dizia que usava. Comunicação também é considerado um dos elementos chave de um time RUP de sucesso.
Aparentemente você teve uma péssima experiência pessoal em algum time que não usava o RUP, mas dizia que usava. Comunicação também é considerado um dos elementos chave de um time RUP de sucesso.
Elemento chave? Voce tirou isso do wikipedia tb?
Sim, estou falando de experiencias reais.
O grande problema dessas experiências ruins do RUP ao meu ver é a sua utilização em projetos pequenos (e até alguns médios) , que não possuem esse tipo de necessidade, ou seja, o famoso usar uma bazuca para matar formiga.
Temos uma metodologia interna aqui na empresa onde trabalho que nada mais é do que uma cópia barata do RUP.
Para os projetos que pegamos, o que noto é realmente esse processo engessado e pesado que alguns descreveram, que acaba no final das contas não trazendo ganho nenhum de produtividade em troca de organização e “papéis bem definidos”. Agilidade cairia bem melhor neste contexto, mas quem sou eu para falar…
http://en.wikipedia.org/wiki/Unified_ProcessO 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.
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.
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.
não fiz não. Primeiro porque embora hajam vários tipos de software só existe um processo de software. Este processo é deterministico e baseado em causa-efeito. Vc não pode implementar regras de negocio sem saber quais são as regras de negocio. O processo de software nasce da recolha de dados do ambiente real (dominio) levado à abstração (analise) e depois condensado em codigo (design e programação).
Várias situações diferentes de deploy não interferem com a metodologia agil porque ela atua internamente à empresa , portanto o método de deploy é irrelevante, o que é relevante é que o produto está pronto a ser entregue. Vc está partindo da suposição errada ( e isto é comum, invelizmente devido a traduções simplistas e expliccações de 5 minutos) de que o stakholder final que recebe o produto de software é o consumidor. Não.
A palavra “Client” em inglês traduzido para “cliente” não significa o consumidor. ou seja, não significa aquele que vai usar o osftware e pagar por ele.
A palavra Client significa aquele que está à espera da entrega e a quem ela é devida. É como no sistema de mensageria que falamos em clientes e estes não são necessáriamente desktops finais. Enfim, o deploy é irrelevante para o uso de agil. A prova é que a industria de jogos usa agil e eles têm um processo bem complicado de deploy ( gravar discos, meter em caixas, transportar, etc… nada disso têm que ver com o software).
Por definição ela não serve para nada. Se vc tem um processo e nele existe uma necessidade de documentação de alguma coisa, isso é uma necessidade. Caso contrário é uma burocracia.
Isso simplesmente não faz sentido. A unica coisa que evita erros é o teste.
Se vc está querendo dizer que a documentação prévia evita erros, errado de novo. Apenas a comunicação evita erros desse tipo, e documentar não é comunicar ( porque falta garantir que alguem lê).
Sim.
não. um erro “não detectado” que pode representar o callback das placas.
Num processo de firmware o teste é conduzido sobre a placa. Considerando que a placa em si não tem erros, qq erro decorrente é do firmware e corrigido no momento. Vc tem 1 software e 1 placa em ambiente de teste. Vc não tem milhares de placas. Assim que esse firmware for exaustivamente testado na placa , passamos a outra bateria de testes com placas semelhantes. Etc… Em nenhum ponto deste processo o usuário da placa teve acesso a ela e em nenhum momento eu recolhi placas já entregues.
A iteratividade é feita durante o desenvolvimento do software. Por definição o desenvolvimento acontece antes do deploy. Vc está misturando as bolas…
Não. Não ajuda. Mas muitos (como você) acham que é uma boa desculpa para waterf… perdão, “processo burocrático”.
Lembre-se que Lean nasceu na toyota onde eles fazem carros numa linha de montagem gigante. O deploy está sendo feito continuamente já que quanto mais o carro se aproxima do fim da esteira mais perto está do deploy. Isto é só para mostrar que coisas de hardware tb podem seguir processos ageis.
Elemento chave? Voce tirou isso do wikipedia tb?Sim, estou falando de experiencias reais.
Eu coloquei um link da wiki, mas caso você não tenha notado, o primeiro link era da IBM. Se quiser, posso linkar mais páginas que mostram que o processo unificado é iterativo. Ou talvez seja melhor você pegar um material impresso, como o já citado livro do Craig Larman.
Não sei de onde você tirou a idéia de que não estou falando de experiências reais. Pelo menos, foi o que você deu a entender na sua frase.
Eu trabalhei junto a uma empresa que não só utilizava, como dava consultoria no processo unificado. E, por sinal, as coisas funcionavam muito bem por lá.
Creio que você deve ter tido experiências ruins por uma coisa que o Sergio vive repetindo. As pessoas usam um processo pela metade e, quando as coisas dão errado, culpam o processo ao invés de culpar a si mesmas.
Você mesmo repetiu várias vezes práticas que são abominadas no RUP, como a falta de comunicação entre analistas e programadores, e waterfall. O RUP é um processo iterativo, comunicativo, baseado em práticas modernas de software. É mais burocrático? Sim, é sim. Mas não é um processo ruim, e há vários casos de sucesso que comprovam isso.
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
Confia apenas na palavra do programador? É claro que documentar não é comunicar, mas a documentação ajuda no processo comunicativo.
A maioria do material que você estuda nada mais é do que um documento, de alguém que entende do processo.
A documentação não precisa ser burra. Pode ser inteligente, com muito material gerado automaticamente. Na verdade, a própria escrita de testes, muitas vezes, é uma espécie de documentação, que é bastante efetiva associada ao relatório da ferramenta que analisa sua cobertura e descreve sua execução.
Como eu falei, o próprio processo unificado estimula que seja assim.
Se vai haver alguém para fazer a conferência, existe a necessidade de documentação, explicando como as coisas foram feitas.
Senão é impossível conferir e se certificar.
Isso é óbvio. Em qualquer processo, os erros devem ser detectados o quanto antes possível. E para isso, há que se garantir que os testes estão sendo executados devidamente. Sem documentação, é mais difícil dar garantias.
Você está falando aqui antes da primeira entrega. E, se você reler o que escrevi, foi quando falei que você realmente poderia ter um processo mais iterativo, que é “entre” as entregas. Entretanto, sua empresa terá que garantir o software da placa mesmo depois de entregue, na mão do cliente final. E é aí o momento em que o erro fica enormemente caro. E é aí que você terá que recolher placas. E, mesmo durante a fase de sustaining, existe desenvolvimento de software.
Eu trabalhei na indústria. E sei o quanto eles são extremamente paranóicos com esse processo. Recolher hardware ou atualiza-lo em campo pode ser catastroficamente caro. Assim como recall de automóveis. E, mesmo a indústria automobilistica e aeronáutica, que desenvolveram muitos dos processos ágeis, ainda são extremamente burocráticas.
Por isso, antes da geração do lote, é comum que hajam processos mais burocráticos. Relatórios que permitam a rastreabilidade, verificabilidade e cobertura dos testes. Documentos que permitam identificar erros de processo, para aquele produto que retorna. Identificar que falhas ele pode conter, e se será melhor repara-lo ou simplesmente atualizar seu software.
É lógico, para que eles sejam efetivos, é preciso gera-los corretamente. E também é importante gerar apenas os dados mais relevantes.
Também é importante diferenciar as coisas. O RUP considera as manutenções, mesmo após o deploy, como parte do ciclo de desenvolvimento de software. Afinal, isso existe. As empresas não viram as costas simplesmente e ficam isentas de compromisso. O software, mesmo depois de entregue ao cliente final, é analisado e permanece em desenvolvimento. Seja para a inserção de novos features ou correções de bug. É lógico que podem haver ciclos antes do deploy com clientes diferentes do final. Em momento nenhum negligenciei isso. Mas o objetivo final da empresa não é agradar a esse cliente, e sim, aquele que vai ser o mais chato, e que estará na ponta final do processo.
E não se pode negar que as coisas ficam muito mais fáceis quando esse cliente pode receber atualizações, sem nem mesmo perceber que isso aconteceu, como ocorre nos ambientes web hoje em dia.
Embora eu tenha repetido milhares de vezes que usa-se ciclos iterativos, sprints curtos, fases de poucos meses, você ainda insiste em dizer que defendo waterfall. Bom, a forma irônica como você falou, para mim é FUD, uma mostra que quando os argumentos acabam, é uma boa tentar ridicularizar aquele que fala.
Como eu já repeti dezenas de vezes, nenhuma empresa de software hoje em dia deve usar ciclo waterfall. Nenhuma. Eu não recomendaria ciclos de mais de 2 meses (que já considero extremamente longos) para a mais rígida e burocrática empresa de software existente. O problema de discussões desse tipo, é que se você desvia um milímetro da opinião dos “ágeis”, você estará falando de um processo “extremamente burocrático e 100% waterfall”. Será realmente que você não está lendo o que escrevi?
E, só para constar, eu trabava com Extreme Programming e hoje com Scrum. Ambos os processos ágeis, e ambos ótimos, na minha opinião.
Só um último comentário. Não é nesse sentido que estou usando a palavra burocracia. Você deu uma conotação pejorativa, que nada tem a ver com o que estou falando.
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.
Eu concordo com você, Vinícius. Mas já me desvirtuei da conversa por motivos de falta de educação… Nem todos são gentlemen. Mas estou de acordo em praticamente tudo o que você falou.
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.
:shock: :?:
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.:shock: :?:
Exatamente. Aparentemente vc sofreu na mão de alguma chefia irresponsável. Alguma empresa que usava processo waterfall, tinha uma hierarquia que mais lembrava a do exército. E, para não dizer que a culpa era dos funcionários (não estou incluindo você, mas geralmente são os implantadores do processo “revolucionário”), falavam que “o RUP é assim”. E agora está descarregando sua frustração (consciente ou inconscientemente) aqui no fórum.
Infelizmente, estamos cheios de empresas assim. Eu mesmo já trabalhei numa (sorte que não por muito tempo), e tive diversos colegas que trabalharam também. No caso da minha, não era o RUP, mas atribuam a própria incompetência ao processo da Microsoft (aliás, alguém se lembra desse processo?)
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.:shock: :?:
Exatamente. Aparentemente vc sofreu na mão de alguma chefia irresponsável. Alguma empresa que usava processo waterfall, tinha uma hierarquia que mais lembrava a do exército. E, para não dizer que a culpa era dos funcionários (não estou incluindo você, mas geralmente são os implantadores do processo “revolucionário”), falavam que “o RUP é assim”. E agora está descarregando sua frustração (consciente ou inconscientemente) aqui no fórum.
Infelizmente, estamos cheios de empresas assim. Eu mesmo já trabalhei numa (sorte que não por muito tempo), e tive diversos colegas que trabalharam também. No caso da minha, não era o RUP, mas atribuam a própria incompetência ao processo da Microsoft (aliás, alguém se lembra desse processo?)
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, mas sim uma versao incremental de waterfall.
waterfall?! ou seria waterfail?! ainda se usa isto?
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.
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?
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…
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.
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.
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.
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.
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”!
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.
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.
Prezado Mochuara, tem base bibliográfica para suportar as afirmações do paragrafo citado acima?
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).
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.
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…
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á
E esse artigo aqui?
http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENGEle é 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
E esse artigo aqui?
http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENGEle é 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.
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.
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.
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.
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.
Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).
IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)
Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
Agil só se aplica antes da primeira entrega. Agil só se aplica para desenvolvimento.
Vc pode subverter/modificar para usar depois do desenvolvimento, mas isso não o que estamos falando.
Se está falando nos problemas pós entrega, agil não é para isso.
Se estamos falando dos problemas pré-entrega, então sim.
Agil define “entrega” como meta. Ou seja, não ha nada além disso.
Depois da entrega vc está de volta no mundo “não-agil”
Claro que vc pode até ter um mecanismo agil para toda a empresa (dificil , mas suponhamos que é verdade).
Nesse caso se a placa tiver algum problema será outra equipa a tratar do recall, etc…
A Toyota usa LEAN. E ha pouco tempo fez um recall. Uma coisa não tem nada a ver com a outra. Mas veja que o recal foi devido a um problema nos requisitos do carro (alguma coisa sobre tapetes se ñ me engano) nada em relação à construção do carro. Ou seja, a parte LEAN funcionou. Apenas alguem alimentou o processo com requisitos de má qualidade.
Em Agil não. “Desenvolvimento” é o que acontece até à entrega.
Se houver um ciclo de manutenção, existirá uma nova entrega e portanto um novo “ciclo agil”. Esta nova entrega é diferente da primeira em termos de objetivos, entradas e saidas. Vc pode aplicar agil a entre novo ciclo, mas não é disto que estamos falando quando falamos de agil sem mais adjetivos.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
Acho que o vini quis dizer foi o falso positivo. não é questão do teste simplesmente passar, mas a forma como foi elaborado. a forma como o teste se desenrola dentro do código não é preocupação da ferramenta, apenas se deu certo ou não. por isso é importante ter registrado de alguma forma como deve se comportar o teste. Ou seja, o comportamento só pode ser examinado por pessoas. é aí que entra algum wiki ou qualquer outra forma de deixar isso claro para pessoas o enredo.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
Acho que o vini quis dizer foi o falso positivo. não é questão do teste simplesmente passar, mas a forma como foi elaborado. a forma como o teste se desenrola dentro do código não é preocupação da ferramenta, apenas se deu certo ou não.
Isso simplesmente não é verdade. O Cobertura, por exemplo, determina - durante o teste - quais linhas foram executadas e quais não.
Se o seu ferramental não analisa o desenrolar do codigo, então use um que analisa. Se é que realmente precisa disso.
Existe uma coisa chamada Requisito. O testes tem que está em conformidade com o requisito. Realmente o o fato de passar ou não, não signifca que está tudo ok. ( um teste vazio passa). Mas ai entramos no mérito da construção dos testes.
O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.
A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.
não. Esse é o pensamento burucrático de que falei. A documentação deve dizer o que esperar do teste, não como construir o teste. O “como” é capacidade do programador. Se ele não a tem, arranje outro. No máximo existe uma documentação sobre o framework de testes ( como o junit e afins) e como o usar, mas isso não é dizer o que esperar do teste.
Exemplo:
Consistencia: A função de soma deve ser cumutativa.
Como testar isso ? O programador deve saber que deve invocar o método com a ordem a,b dos argumentos e depois com a ordem b,a e o resultado deve ser o mesmo para todos os a,b. Como não pode testar todos os a,b , testa os limites. os menores e maiores valores de a e b. zero e null (se permitido) e um ou dois valores escolhidos aletoriamente.
Ninguem vai documentar o codigo, ou pseudo codigo deste teste. isso é suicídio.
O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.
Espere um pouco, você por acaso pulou essa linha?
Sim, o IC garante, por que as ferramentas do IC geram documentos, descrevendo o resultado dos testes de cobertura e demais testes. E o conjunto de documentos desses ganha o nome de… documentação. Em momento nenhum falei que a documentação, para ser válida, precisa ser feita manualmente. Aliás, acho que o que quote deixa bem claro o contrário.
Manter guardado o relatório do IC é manter documentação. Se algo falhar em campo, você vai querer ver esses dados, para detectar onde a falha ocorreu. E vai ser ainda mais grave se nenhum relatório desse tiver sido gerado, pois indicará que você queimou uma etapa do processo.
Mesmo os processos ágeis guardam documentação além do requisito. Como por exemplo, o javadoc dos principais métodos ou ainda a exigência do uso da tag @author, @version. Nada disso é requisito funcional.
O requisito é a documentação mais importante, de fato. Mas já trabalhei com softwares críticos que seriam muito complexos de entender sem um pouco mais de documentação do que o código fonte, os javadocs e os testes. Em software otimizado, você desconstrói a refatoração em prol de performance, e precisa ter clara as metas de execução de determinadas funções (porque elas tornam-se parte do requisito). Nesse caso, muitas vezes é comum recorrer a diagramas.
Aliás, um diagrama macro, que mostre como as camadas de sua aplicação se organizam também é muito comum.
O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.
Espere um pouco, você por acaso pulou essa linha?
Sim, o IC garante, por que as ferramentas do IC geram documentos, descrevendo o resultado dos testes de cobertura e demais testes. E o conjunto de documentos desses ganha o nome de… documentação. Em momento nenhum falei que a documentação, para ser válida, precisa ser feita manualmente. Aliás, acho que o que quote deixa bem claro o contrário.
Manter guardado o relatório do IC é manter documentação. Se algo falhar em campo, você vai querer ver esses dados, para detectar onde a falha ocorreu. E vai ser ainda mais grave se nenhum relatório desse tiver sido gerado, pois indicará que você queimou uma etapa do processo.
Acho que não estou me fazendo entender. Nada vai para campo se aconteceu alguma falha. Se algo foi para campo é porque todos os testes eram verdes. Logo, se aconteceu um problema no campo e foi identificada uma falha só nesse momento, isso não tem nada que ver com IC. O IC não vai descobrir esse erro a menos que um teste seja adicionado que levanta essa falha. mas isso é feito depois que o erro acontece.
O senário seria : 1) o IC está verde. 2) a placa é entregue. 3) um problema aconteceu no campo 4) a placa retorna
5) o problema é identificado 6) um teste é montado para idenificar o problema à priori ( supondo que se pode) 7 ) o teste é adicionado ao IC.
8) o IC é aplicado às novas placas e placa velha é modificada ou destruida e substituida por uma nova devidamente testada com o novo IC.
Não estamos falando da documento gerada como javadoc, relatorios de testes etc… estamos discutindo se o processo agil é aplicado pós deploy ou não. Vc argumentou que num processo com deploy externo como o de uma placa de hardware com firmware não seria possivel aplicar agil porque nao ha como retornar todas as placas para serem corrigidas. Eu argumentei que o processo agil não abrange a fase pós-produção.
Mesmo que o firmware podesse ser atualizado via internet automaticamente esse processo não estaria no ambito do processo agil. O processo agil teria terminado no momento que o patch ficou disponivel para download. É o problema do conceito de entrega.
A documentação que atrapalha não é a automática, nem a de pós-produção é a de pré-produção. É ai que o agil defende a comunicação e não a documentação. Ou seja, nada de criar documentos monstruosos antes do codigo. Documentos só podem ser criados depois do codigo, a menos é claro que sejam codigo em si mesmos (como testes de aceitação automatizados).
Contudo, o scrum em particular , parte do documento de visão que é elaborado antes da construção. Além disso parte do backlog e dos release backlogs que são feitos antes também e do spring backlog que é feito antes. Mas repare que estas coisas são documentos de intensão (são desejos e checklists) não são requisitos e não são documentação ( excepto o documento de visão). são artefatos de controle gerencial e não constituem entregáveis. São, por assim dizer, meta-documentos.
A falha em criar estes artefactos com qualidade leva a um caos igual ou pior que a falha em criar bons documentos de requisitos no modelo classico.
O scrum, tb em particular, sugere que exista um documento não código que é o manual do usuário. Este documento serve tanto como requisitos como check list como documento para ensinar a usar o sistema. E é considerado o alter-ego do código.
Portanto, logo aqui, no scrum vc tem pelo menos 3 documentos : visão, manual de usuário e código.
visão = o que queremos para o futuro / o que queriamos no incio do projeto
manual = o que obtivemos no final
codigo = como obtivemos.
Acho que não estou me fazendo entender. Nada vai para campo se aconteceu alguma falha. Se algo foi para campo é porque todos os testes eram verdes. Logo, se aconteceu um problema no campo e foi identificada uma falha só nesse momento, isso não tem nada que ver com IC. O IC não vai descobrir esse erro a menos que um teste seja adicionado que levanta essa falha. mas isso é feito depois que o erro acontece.O senário seria : 1) o IC está verde. 2) a placa é entregue. 3) um problema aconteceu no campo 4) a placa retorna
5) o problema é identificado 6) um teste é montado para idenificar o problema à priori ( supondo que se pode) 7 ) o teste é adicionado ao IC.
8) o IC é aplicado às novas placas e placa velha é modificada ou destruida e substituida por uma nova devidamente testada com o novo IC.
Sim, o que estou dizendo é que, quando a falha ocorrer, você precisa ter certeza que a equipe efetivamente fez a integração. Deve ter condições de olhar o relatório do Code Coverage e ver se realmente nada ficou faltando. E isso, só será feito através da documentação gerada pela ferramenta.
Não, não foi isso que argumentei. Eu argumentei que você pode usar processos ágeis até exatamente antes do deploy. Que as indústrias exigirão mais documentos garantindo o processo como um todo, antes de liberar um produto no mercado.
Sim, e foi por isso que fiz questão de frizar a diferença dos dois processos. O processo unificado conta como desenvolvimento as fases que sucedem a manutenção. Para ele, os documentos gerados devem contemplar a fase de manutenção do código, e devem prover os feedbacks necessários para que a manutenção ocorra de maneira suave. Outra coisa é que o Processo Unificado foi idealizado para equipes enormes de desenvolvimento, por isso, acho que não compensa utiliza-lo em equipes menores. Para elas, ele é realmente burocrático demais.
O processo unificado também condena a criação de documentos monstruosos antes do código. É um princípio que você só deve elaborar um documento, caso ele traga valor ao entendimento do sistema. Como eu falei, acho que processo sério nenhum defende a documentação pela documentação.
Um problema sério são os estereótipos vendidos pelos livros por aí. Se você lê um livro ágil, quem usa rup está “num processo em cascata, perdendo tempo com documentos inúteis”. Se você lê um livro sobre o processo unificado, os processos ágeis são “sem metodologia, baseados na bagunça”. Bem, ambas as visões não são verdade.
O que existe, de fato, são empresas que entendem errado o processo unificado e fazem com ele o que outras fazem com o ágil: Não o implementam direito. E aí, culpam o processo. Se você vai usar o processo unificado, você não deve, por exemplo, hierarquizar sua equipe. O processo é bastante firme em defender que o analista não é “chefe” do programador. E que o programador não é um pedreiro. Ambos devem estar em constante comunicação. Ele também defende ciclos bastante curtos, com pouca documentação gerada. Mais do que os processos ágeis, claro, mas para uma equipe maior, uma documentação ainda assim necessária.