[quote=Emerson Macedo]
Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.[/quote]
Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.
Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.
Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.
Carinha, que coisa bacana que você disse; parabéns!
Nada contra as metodologias porem quando o verdadeiro desafio se apresenta, certamente o que conta são a habilidade e a criatividade do individuo ou da equipe em questão.
[quote]=Bruno LaturnerAliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.
[/quote]
Isto que você disse já rendeu muita grana para consultorias e vendedores de cursos. Quem disse que burrice não rende dinheiro?
[quote=Bruno Laturner][quote=Emerson Macedo]
Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.[/quote]
Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.
Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.
Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.[/quote]
Calma lá, está dizendo que desenvolver software é uma atividade complexa e requer profissionais capacitados!?!? Então vc precisa receber a visita de um dos nossos consultores RUP ou especialistas agile!!!
Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.
Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:
Abraços,[/quote]
Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.
Qual o problema de render dinheiro a quem entrega cursos/treinamentos? E livros? E blogs?
Cuidado… será que não estamos invertendo as coisas? Qual o problema de ganhar dinheiro ao ensinar uma técnica nova ou melhor?
Outra coisa, você disse “Nada contra as metodologias porem quando o verdadeiro desafio se apresenta, certamente o que conta são a habilidade e a criatividade do individuo ou da equipe em questão.”
Metodologia, pra mim, é como ferramenta: serve pra ajudar. Ela sozinha não faz nada.
Uma frase que gosto demais é do Grady Booch: “Um bom time sem processo adequado sempre será superado por um bom time que aplica um bom processo.”
Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.
Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:
Abraços,[/quote]
Opa Emerson, concordo discordando: o RUP não é mau documentado. Na minha opinião ele é bem documentado DEMAIS. Tem tudo lá. E esse, ao mesmo tempo, é uma fraqueza e uma virtude.
Para iniciantes, documentação (do processo!) por documentação, fico com a do SCRUM: as simpler, the better.
Como sei RUP de trás pra frente, me dou muito bem com o bixo. Mas dificulta muito a vida de quem está começando.
Para esses, recomendo fortemente o livro do Philip Krutchen (um dos padrinhos e mantenedores da criança) “RUP Made Easy”. Eu aprendi direito por ele.
[quote=Bruno Laturner][quote=Emerson Macedo]
Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.[/quote]
Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.
Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.
Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.[/quote]
Concordo totalmente contigo. A um tempo atrás escrevi um post entitulado “Paranóia mMetodológica tem cura!”
[quote=mochuara]
Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.[/quote]
Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?
[quote=rodrigoy][quote=mochuara]
Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.[/quote]
Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?
É culpa do RUP? Não. RUP é um bom processo.[/quote]
[quote=rodrigoy][quote=mochuara]
Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.[/quote]
Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?
É culpa do RUP? Não. RUP é um bom processo.[/quote]
Isso não prova que RUP esta morto. Na verdade, o fato de haver pouca demanda por consultores para introduzir RUP nas empresa é de esperar dado que se trata de um processo estabelecido no mercado.
Ainda assim, isso tb não prova que RUP não esta sendo mais usado em novos projetos, já que vc não é o unico consultor RUP no mundo.
[quote=pintofree]So pra constar meu apoio, RUP realmente não É waterfall.
Muita gente usa assim e pensa assim, mais nao é[/quote]
Muita gente usa assim porque assim que melhor se adequa às necessidades de comunicação da empresa. Ou seja, por mais que vc não goste de waterfall, seu chefe gosta, e é graças a ele que RUP foi amplamente adotado pela indústria como processo waterfall. Ninguém da a mínima se um acadêmico acha que é melhor usar de outro jeito.
[quote=sidzuza]Cara, RUP é um processo iterativo sim e qualquer documentação a respeito do mesmo diz isso.
Se na prática as pessoas não o fazem iterativamente é outra estória.
Sua afirmação não tem fundamento e só está servindo para aumentar sua quota de mensagens[/quote]
Sua afirmação que não tem fundamento. Processos são guias de como agir, se RUP não consegue ser traduzido na prática num processo iterativo (isto é, sem separação entre analise e implementação) então ele é waterfall e ponto.
Cara o RUP é interativo e incremental, inclusive na documentação do RUP existem modelos para implementação do processo em equipes agéis utilizando somente um conjunto dos artefatos.
Nesse mesmo capítulo, também existem exemplos e formas de implementar o processo em diversos tipos de projeto. Quem disse que a documentação do RUP é falha, é porque não a leu.
Para mim a diferença do RUP para as metodologias ágeis está mais relacionada a princípios, valores e práticas adotadas pela equipe do que em artefatos e documentação produzida.
Todo mundo levanta requisitos, implementa, testa, implanta e controla o processo no final das contas.
Quando saiu da Rational o Ivar Jacobson criou o Essencial Unified Process baseado na sua experiência com o RUP e lendo esse processo notei semelhanças com os modelos propostos na documentação do RUP que citei aqui no inicio.
Metodologia é uma ferramenta para auxílio no gerenciamento, cada um deve escolher as ferramentas que se adequam melhor a sua equipe.
Que RUP é iterativo na teoria porque assim diz a documentação já foi dito nessa thread, portanto seu post não agrega nada a discussão.
Mas essa afirmação me chamou a atenção:
“Todo mundo levanta requisitos, implementa, testa, implanta e controla o processo no final das contas.”
Quem “levanta requisitos” já parte do pressuposto que 1) não sabe o que deve ser construído, 2) quem sabe não faz parte da equipe, 3) e que, por isso, análise e implementação devem ser feitos separados.
Portanto entenda que levantar requisitos é o primeiro indicativo que seu processo não é iterativo.
Filho você sabe o significado de Iteração? O fato de ser haver um ciclo não quer dizer que o processo completo tem somente uma iteração.
Dai vem o fator incremental.
Primeiro ponto: User Stories ou Use Cases são modelos de requisitos levantados.
Segundo ponto: Saber e expicar o que vai ser construído faz parte das atribuições do analista/programador e participar do levantamento dos requisitos também. (Inclusive no RUP).
Você levantou o pré-suposto e pulou uma etapa do inicio de cada fase baseado em que? Que seu cliente ou analista de negócio vai levantar os requisitos (Inclusive Técnicos) sozinhos? Onde você leu isso isso no RUP?
Clientes e analistas de negócio não precisam levantar requisitos, ora, eles sabem o que precisa ser construído, por isso são, advinha, especialistas no negócio…
Um projeto de software que não pode contar com a presença de especialista no negócio esta fadado ao fracasso antes mesmo de começar e quando podemos contar com as condições mínimas, que é a presença desses profissionais, não há porque levantar requisitos, porque eles já são conhecidos. Acontece que levantamento de requisitos no RUP, é na verdade, um pretexto para waterfall. Com o tempo gerentes aprenderam a dividir a cascata em fases porque descobriram que poderiam controlar melhor, e ainda fazer uso de um menor número de recursos. Assim surgiu o RUP.
Ou seja, a finalidade do “levantamento de requisitos” é para que gerentes tenham um papel entre os reais especialistas do negócio (clientes/analistas de negócio) e os reais implementadores (programadores), funcionando assim como intermediário e podendo exercer controle sobre uma parte importante do processo, sem que para isso precisem de avançado conhecimento técnico (sobre software ou sobre o negócio). Basta traduzir o que se sabe sobre as necessidades do projeto em instruções de alto nível, capazes de serem seguidas por programadores dispostos a executarem um trabalho medíocre, em nome de usuários que só existem na forma de diagramas de casos de uso e especificações incompletas.
Portanto, fica a dica, uma boa forma de identificar se o processo não é iterativo é se ele recomenda começar levantando requisitos.