> Eu estou iniciando o primeiro projeto "oficialmente" XP na minha empresa e embora
> a princípio as idéias possam parecer absurdas o processo tem se mostrado eficiente.
Eu no meu primeiro projeto usando RUP não estou achando RUP nada
efficiente. Estou me achando até uma crianca fazendo soh desenhos na
tela ;-) Do outro lado as diagrammas de classe e sequencia dá uma visão
geral para o equipe e até para mim. Eu nunca ouvi falar de XP até agora
mas já trabalhei em varias empresas usando metodologia similar.
>
>
> Do meu ponto de vista XP é uma melhor metodologia do que os chamados "processos
> pessados" pelos seguintes motivos:
>
> - Mudanças acontecem durante o projeto, independente de quão detalhada tenha
> sido a sua análise de requisitos.
> - O cliente não compra modelo ou comentários no software, compra o software.
> - Documento não substitui comunicação com o cliente
>
> A idéia de que XP é contra as tarefas de design é uma falha de marketing dos
> defensores de XP :). Na verdade XP defende que a análise seja feita "just in time"
> (Porque os requisitos mudam :-). É o processo iterativo levado ao extremo.
Na minha opinião isso estah completamente certo. Imagina o seguinte
requisito:
Cliente: "Eu quero um sistema que faz tudo, administração de clientes,
estouque, vendas, telemarketing , rh etc"
Tudo bem voce pode ir la com alguns analistas, fazer aquela documentação
todo, montar diagramas, codificar, testar.
Quando na fase de testar vo tem que testar tudo de uma vez so.
A minha maneira preferencial de trabalhar seria pegar a coisa parte port
parte. Já que um sistema desse dependeria muito de clientes, començar
ai. Nada impede vc criar diagrammas se quiser, mas deixando a coisa tão
basico provavelmente não precisa. Testar o software é facil tambem,
somente tem aquele modulo para testar.
> telefonemas e emails com eles para redefinir os requisitos. Acredito que as práticas
> de XP teriam removido todo o overhead que tinhamos com o RUP e teria posto disciplina
> no "processo leve" que sem pensar muito acabavamos usando.
O maior problemo com RUP é que na verdade é dificil achar um cliente que
sabe exatamente o que quer. Temos um projeto em fase de
levantamento(web) - o cliente quer RUP - ai estão estudando lah aqueles
use-case diagrams, agora o cliente quer ver as telinhas (HTML) pois não
consegue visualizar. Pelo que saiba RUP não tem telinhas.
>
> em um projeto para 3os, o seu cliente tem que ter confiança na sua empresa, pois
> geralmente os clientes querem ter um monte de papel na mão dizendo exatamente o que o
Poizz eh, mas será que monte de papel gera codigo confiavel ?? Se o
arquiteto falha no design de classes, no RUP é muito mais complicado
concertar o erro, precisa de uma nova iteração,
>
> sistema vai fazer, e o quanto eles vão pagar por isto, o que não é possível em XP,
> pois o levantamento de requisitos inicial é um conjunto de histórias contadas pelo
> usuário (E não pelo analista!),
Eu acho, que um analista bom tem que ter experiencia em que esta
analisando e tem que ter experiencia em outras coisas e muito paciencia.
Participei num projeto na Holanda un 7 anos atras para uma empresa que
tem varias hoteis e pousadas etc. O sistema era para reserva de quartos
nos hoteis. Era o requerimento da empresa, que todos que trabalhariam no
projeto teriam pelo menos 1 mes de experiencia no telefone deles. O
resultado era uma maravilha. O que acontece numa area de televendas o
gerente não consegue passar para uma analista, ele tem q ver.
Vou me lembrar deste site ;-)
Sven
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
