Leonardo,
> Fala Alexandre,
>
> 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.
As id�ias n�o s�o t�o absurdas assim. Quem mais se dedica a divulga��o do XP
� o Kent Beck que, nos anos 80, trabalhava no laborat�rio de pesquisa da
Tektronix, que era refer�ncia, na �poca, em tecnologia de objetos.
Para vc ter uma id�ia, a t�cnica dos cart�es CRC
(Class-Responsibility-Collaboration) que at� hoje � bem aceita, saiu de l�.
> Do meu ponto de vista XP � uma melhor metodologia do que os chamados
"processos
> pessados" pelos seguintes motivos:
XP n�o chega a ser um processo de desenvolvimento. Por defini��o, ele est�
mais para uma disciplina a ser adotada para a fase de constru��o que
qualquer outra coisa. Tanto � que j� se fala em adapta��es ao RUP
incorporando as caracter�sticas do XP (j� ouvi o termo eXtreme RUP).
> - 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
Creio que vc esteja equivocado ao falar isso. Qualquer que seja o processo
que vc adote, sempre vc ter� que gerenciar o risco das mudan�as de
requisitos por mais �gil que seja a constru��o dos sistemas. Vc sempre ter�
que controlar 4 vari�veis para que seu projeto d� certo: Qualidade, Prazo,
Custo e ESCOPO. XP prega este enfoque em gerenciamento tb. O que normalmente
acontece � que somos negligentes com a vari�vel escopo e todas as outras
ficam comprometidas pondo o projeto a pique.
> 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.
O enfoque em design n�o � dado mesmo. XP est� mais para uma disciplina como
disse anteriormente. Presume-se que isto j� tenha sido feito, que j� se
tenha o design arquitetural macro da aplica��o validado. O refactoring que o
XP tanto prega, resolve problemas de �mbito menor: performance,
simplifica��es, coes�o. Est� surgindo o Agile Modeling (chamado inicialmente
de eXtreme Modeling) para dar suporte a modelagem conjuntamente ao XP.
> Na empresa em que eu trabalhava antes (Revendedora de produtos e
treinamento
> rational :-)) eles gostavam de falar que seguiam um processo que era uma
instancia do
> RUP, mas quando eu olho para os projetos de que eu participei eu vejo que
nunca
> conseguimos seguir estritamente um processo semelhante ao RUP. Sempre que
o bixo
> pegava deixavamos de lado aquele monte de diagrama bonito e codificavamos.
Faziamos
> levantamento de requisitos, escreviamos os use cases e na hora de
implementar eles
> n�o estavam totalmente completos ou o cliente mudava de opni�o e ficavamos
trocando
> 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 que vc demonstra aqui � que a causa principal dos seus problemas era a
falha no gerenciamento do projeto em si, do escopo do projeto. N�o estou
defendendo o RUP mas nenhum processo funciona sem uma ger�ncia efetiva e um
conhecimento profundo das necessidades do cliente (n�o � a toa que o XP
sugere que o cliente esteja dispon�vel sempre aos programadores e que at�
mesmo trabalhe em conjunto com a equipe).
> Pra n�o falar que XP � a solu��o pra todos os seus problemas - ia
parecer at�
> propaganda de produtos tabajara - o �nico problema de XP � que para ele
funcionar bem
> 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
> 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!), cada uma descrevendo uma funcionalidade do
sistema em
> no m�ximo dois paragrafos. Seria algo como um use case simplificado, sem
todos os
> detalhes do requisito, com somente o necess�rio para fazer uma estimativa
do custo e
> risco do requisito e planejar o cronograma de desenvolvimento.. durante a
itera��o em
> que a hist�ria fosse ser implementada, os desenvolvedores iriam obter com
o cliente
> os detalhes e implementar a hist�ria.
As hist�rias no XP s�o an�logas aos use cases sim, em uma granulidade maior,
podendo representar os fluxos dentro de um use case. O problema � que fica
muito dif�cil dimensionar o tamanho do projeto dessa forma, vc n�o tem uma
vis�o global (no caso, o diagrama de casos de uso) para, no m�nimo, estimar
os custos de um projeto com pre�o fechado.
> Em http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap voc� vai
encontrar tudo
> sobre Xp, inclusive o projeto que estou iniciando :)
> http://www.c2.com/cgi/wiki?TheMarbleProject
>
> Como eu estou apenas iniciando o meu primeiro projeto usando XP eu
tenho muitas
> d�vidas e gostaria de trocar id�ias com interessados nesta metodologia..
se mais
> algumas pessoas tiverem interesse poderemos criar um grupo de discuss�o...
mais
> alguem se interessa por XP?
Realmente XP � muito empolgante pela sua din�mica mas tb tem suas
limita��es. Sabe-se que ele n�o funciona em equipes grandes (equipe de at�
10 pessoas � aceit�vel). A figura de um gerente e de um "treinador" tb �
important�ssimo para que o XP flua. Portanto, analise se seu projeto se
adequa a essas e outras limita��es e requisitos.
Mas meus parab�ns pela iniciativa.
Bene.
> Inteh,
> Leonardo.
> ...................................................................
> Leonardo Souza Mario Bueno
> Itera - Voice, Wireless & Web Solutions
> [EMAIL PROTECTED]
> Phone: 55 27 337 0317
> Cell: 55 27 9971 1375
> Visit our website at:
> http://www.itera.com.br
> ...................................................................
------------------------------ 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]
-------------------------------------------------------------------------
