----- Original Message -----
From: "Bene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 20, 2001 8:17 PM
Subject: Re: [java-list] eXtreme Programming
> 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�.
� o que eu disse... "Embora as id�ias possam parecer.." :)
>
> > 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).
Tente falar isso pro Beck... acho que XP � sim um processo. XP define as pr�ticas
e os momentos em que elas devem ser empregadas. E n�o creio que ela seja adotada
somente para ao equivalente a fase de constru��o pois XP define como se faz o
levantamento de requisitos, o planejamento e o design.
http://www.c2.com/cgi/wiki?ExtremeProcess
>
> > - 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.
Quais pontos est�o errados? Quando eu falei que que n�o se deve gerenciar estas
veri�veis que voc� sita?
>
> > 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.
N�o, n�o.. em XP n�o se pressup�es nenhum grande design inicial.
O �nico design inicial feito � uma met�fora do sistema e o que chamam
de SpikeSolution, que seria como um prot�pipo.
http://www.c2.com/cgi/wiki?AdequateArchitectureUpFront
Em XP se faz design, o que n�o se faz � o design para documenta��o, o design
detalhado do que ser� implementado daqui a 4 itera��es..
>
> > 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).
Realmente havia uma falha muito grande no gerenciamento. O problema era o seguinte,
a estimativa era que o projeto demoraria 8 meses para ser concluido, o cliente so
admitia
4 meses... ent�o tinha que ser em 4 meses. :-)
>
> > 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.
N�o entendi o que voc� quis dizer com "podendo representar os fluxos dentro
de um use case".
Em XP voc� tem uma cole��o de hist�rias que tem seu custo estimado em semanas
ideais de programa��o, que seria o tempo necess�rio para voc� implementar a hist�ria
se voc� n�o tivesse nada lhe desviando a aten��o e nenhuma dependencia em outros
recursos ou trabalho de 3os. Al�m disto, cada projeto tem o que se chama de
"velocidade de projeto" que � o n�mero de semanas ideais de trabalho que podem
ser realizadas em uma itera��o (Ex: em uma itera��o de 3 semanas, "cabem" 1,5
semanas ideais) sendo que esta velocidade de projeto muda a cada itera��o,
se voc� implementar mais do que o estimado inicialmente, a velocidade aumenta, se
voc� implementar a menos ela diminui.
Se sempre estimassemos com precis�o a velocidade inicial de projeto (Se ela se
mantivesse constante durante todo o projeto) ent�o teriamos como de in�cio
falar: vai demorar X semana a um pre�o pre�o Y com qualidade m�xima :) para
implementar as hist�rias A,B,C,D.
O problema � que em XP o cliente pode, a qualquer momento, mudar o escopo
do projeto, criando, alterando e descartando hit�rias...
Veja que no RUP se faz algo parecido, o que muda � que no RUP se faz muito
design inicial, muito mais documenta��o e a velocidade do projeto � tida como
constante.
>
> > 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.
J� t� analisado :-)
>
> Mas meus parab�ns pela iniciativa.
Brigad�.
>
> Bene.
[],
Leonardo.
>
> > 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]
> -------------------------------------------------------------------------
>
------------------------------ 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]
-------------------------------------------------------------------------
