Usando um processo ágil cada iteração deve ser “entregue” ao cliente, então isso serve como uma “prototipação”
[/quote]
Com certeza. Pelo menos no RUP, a utilização de ‘pequenos protótipos’ é recomendada porque a cada iteração realizada você pode mostrar ao cliente. Ocorre uma evolução do protótipo até chegar ao ‘produto final’ (apesar que não existe produto final porque o software nunca é finalizado completamente… :D…sempre existem modificações a fazer )
Até mais
Patty[/quote]
Você considera RUP um processo ágil?[/quote]
Saiu essa discussão aqui no tópico sobre protótipo…
O RUP é um framework. Ele ser ágil depende de como você implementa. Há uma implementação minimalista bastante famosa, chamada dX - em alusão ao diferencial, he he - que se aproxima brutalmente de XP.
Incrível, mas tem clientes que pedem que se use RUP como processo de suporte ao desenvolvimento (não, eu não estou passando mal!). Logo, num caso assim, acho que flexibilizar o RUP para torná-lo ágil é válido. Nos demais casos onde não haja uma cláusula contratual obrigando o uso de RUP, entre flexibilizá-lo ou usar XP/SCRUMM, acho mais fácil a segunda opção.
Acredito que nenhum processo é “out-of-the-box”. Seguir qualquer processo à risca mesmo que seja XP pode te transformar num “tradicionalista”. Certo? :oops:
Você aplica as metodologias [color=red]exatamente[/color] do jeito que a literatura manda? Você não faz algumas adaptações (mesmo que pequenas)?
Acredito que nenhum processo é “out-of-the-box”. Seguir qualquer processo à risca mesmo que seja XP pode te transformar num “tradicionalista”. Certo? :oops:
Você aplica as metodologias [color=red]exatamente[/color] do jeito que a literatura manda? Você não faz algumas adaptações (mesmo que pequenas)?
[/quote]
Eu entendi o que você quis dizer, Rodrigo, mas acho que o ponto que o Carlos quis comentar não foi bem este. Acho que a questão seria: “o que é melhor: ajustar algo que é grande, complexo e tradicionalmente não-ágil como o RUP para torná-lo ágil ou simplesmente adaptar as práticas do XP/Scrumm para as suas necessidades?”.
Daniel, é verdade, bom, podemos usar o AUP nesse caso que a customização já está feita… Mas sobre o que você falou das empresas exigirem o RUP não é fato isolado. Rola direto!!!
Geralmente o gestor que está comprando o projeto acha que estará mais seguro se o processo for distribuido por uma empresa (IBM). Bom, cada louco com a sua mania…
Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.
[quote=Robert]Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.[/quote]
Robert, aí é que vc se engana. Não é que a atividade principal do XP é codificar. Para falar a verdade a maneira de se modelar é que é diferente. Eles usam um modelo mental, ou um modelo rascunhado, ou até mesmo a questão de você fazer os testes antes de codificar é considerado o modelo.
Até mesmo o pair programming pode ser considerado uma atividade de modelagem (um pensa no operacional o outro pensa na tática). Tudo isso é para compensar a especificação mais leve que o processo prega.
Muitos metodologistas defendem que os processos ágeis não são gambiarra e nem mesmo 100% desprovidos de documentação. Como já falei, não gosto quando XP vira desculpa para sair fazendo as coisas sem processo nenhum.
Os gerentes de projetos e afins adoram metodologias como RUP e metodos de qualidade como CMM* simplesmente por que tem muito papel e documento, ( quilos alias ) o cliente precisa ter informacoes sobre o projeto. e ele muitas vezes nao sabe ler codigo, entao … quer tranquilidade melhor para um gerente do que mandar 100 emails por dia com 2 documentos anexados pro cliente “se divertir” e largar do pé do supracitado ?
Papéis e documentos são importantes na medida certa. O problema (que é o que costuma acontecer) é quando tentam usar a burocracia como álibe para prováveis problemas que o projeto enfrentar (e que provavelmente vão existir).
Como eu escrevi em um post no meu blog (é, marketing pessoal mesmo), Horácio já dizia:
Ahhh, se este cara fosse engenheiro de software da SEI hoje em dia…
[quote=Robert]Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.[/quote]
No XP a atividade principal eh entregar software funcinoando o mais rapido possivel - codificar eh uma das coisas necessarias pra isso, mas nao se pode confundir as duas.
cv, aí na fábrica do Fowler vcs estão aplicando sempre XP, ou outras metodologias ágeis? Rola alguns projetos num Unified Process mais tradicional? (casos de uso, design, implementação, teste)
Pergunto isso porque o maior entrave para usar metodologias ágeis aqui no Brasil é o cliente (digo isso em fábrica de software, que é onde trabalhei nos últimos 6 anos). O cliente não quer trabalhar fácil, e muitas vezes nem iterativamente.
