Qual a sua metodologia de trabalho?

De certa forma, eu já até faço idéia do resultado dessa votação

, mas de qualquer maneira, la vai

RUP - http://www.rational.com/products/rup/index.jsp
FDD - http://www.featuredrivendevelopment.com/
XP - http://www.extremeprogramming.org/

Ah, e se passou alguma metodologia despercebida pela listinha de candidatas, é só dar um toque que eu adiciono

eu gosto muito mais das práticas do XP, mas eu uso algo de RUP, como a UML, não os 9 diagramas, geralmente o diagrma de classe, para gerar minhas classes em JAVA, principalmente as classes que serão utilizadas com o hibernate

mas as prática do XP predominam aqui

, entre elas, só não acho o pair programming muito interessante, mas de resto acho muito boa.

Ok, acredito que a votação vai ficar meio "viciada", mas acho que XP é uma ótima metodologia devido ao de todas aquelas chatices "burocráticas" (infinitas fases de análise que não levam a lugar algum, por exemplo) terem sido ou simplificadas ou simplesmente retiradas do processo de desenvolvimento. Uma outra coisa interessante do XP é que ele já embute a filosofia de separation of concerns (SoC). Mas também é preciso de um esforcinho extra para coordenação de times XP para que o projeto acabe não virando uma zona (algo que quase aconteceu aqui na minha empresa).

ManchesteR wrote: só não acho o pair programming muito interessante, mas de resto acho muito boa.

Poxa, por que não? Você é outro partidário do pair debugging do Carlos?
Pair programming é muito interessante, na minha opinião, principalmente quando você está trabalhando em uma equipe cujo grau de conhecimento seja bem heterogêneo.

XP é legal... só a parte de pair program que não curto muito... só em determinadas horas eu uso...

RUP e XP sao bem opostas neh?!! ( ou algo assim.. )..

o que de melhor da pra arrancar dele? pq tem gente que mete o pau no pair-programming, o que parece ser um dos topicos mais falados de xp, e outros adoram...

e em relacao a uma metodologia "hibrida", onde vc pega um pouco de cada uma - o que mais gosta, o que mais se adapta - e faz como sendo a sua metodologia?

Rafael

r_linux wrote:XP é legal... só a parte de pair program que não curto muito... só em determinadas horas eu uso...

Afinal, por que vocês não gostam de pair programming?

Eu aposto que a maioria aqui na hora de fazer a modelagem usa SFML em vez de UML...

Daniel Quirino Oliveira wrote:

r_linux wrote:XP é legal... só a parte de pair program que não curto muito... só em determinadas horas eu uso...

Afinal, por que vocês não gostam de pair programming?

bom, eu nunca nem tentei, mas falando com um pessoal um tempo atras, eles soh diziam "ah, isso nao funciona.. onde ja se viu, 2 caras por pc.. isso eh jogar dinheiro da emprsa fora"..

eu tinha/tenho uma ideia razoavel sobre pair programming, entao rebatia com coisas como ".. vc prefere gastar no total 10 horas dos teus programadores para resolver o problema ou gastar 10 horas de cada um, quando eles trabalham separadamente?" .. ( nao sei se eh valido isso, mas mesmo assim era o q eu dizia hehe )..
bom.. se bem que ".. para resolver o problema.. " mais parece como debug do que como coding mesmo..

Rafael

Daniel Quirino Oliveira wrote:

ManchesteR wrote: só não acho o pair programming muito interessante, mas de resto acho muito boa.

Poxa, por que não? Você é outro partidário do pair debugging do Carlos?
Pair programming é muito interessante, na minha opinião, principalmente quando você está trabalhando em uma equipe cujo grau de conhecimento seja bem heterogêneo.

Daniel, você tocou no ponto principal do pair programming (na minha opinião), que é quando você tem equipe muita heterogênia, ou seja, um membro sabe mais que o outro, ae se por os dois para programarem juntos, um acaba ensinando o outro.

O Pair debbuging sim é interessante, mas depende muito do caso e muito do problema, e também do nível de conhecimento de quem o for fazer.

Agora o porque eu não gosto muito do pair programming, é que eu não achei vantagem em colocar duas pessoas para programarem juntas, acho que você perde mais tempo do que ganha (posso estar errado), mas nos projetos nossos aqui, cada um programando em funcionalidades diferentes, deram mais resultados, sim sim, nós já fizemos um teste com pair programming para ver. Acredito que em funcionalidades complexas, onde você não tem nada pronto, onde é um novo mundo que irá entrar, perfeito, pair programming funciona, mas se for alguma funcionalidade que você ja implementou, ou algo que irá fazer um refactor, acredito que duas pessoas seja perca de tempo.

isso tudo IMHO é claro

ManchesteR wrote:

Daniel Quirino Oliveira wrote:

ManchesteR wrote: só não acho o pair programming muito interessante, mas de resto acho muito boa.

Poxa, por que não? Você é outro partidário do pair debugging do Carlos?
Pair programming é muito interessante, na minha opinião, principalmente quando você está trabalhando em uma equipe cujo grau de conhecimento seja bem heterogêneo.

Daniel, você tocou no ponto principal do pair programming (na minha opinião), que é quando você tem equipe muita heterogênia, ou seja, um membro sabe mais que o outro, ae se por os dois para programarem juntos, um acaba ensinando o outro.

O Pair debbuging sim é interessante, mas depende muito do caso e muito do problema, e também do nível de conhecimento de quem o for fazer.

Agora o porque eu não gosto muito do pair programming, é que eu não achei vantagem em colocar duas pessoas para programarem juntas, acho que você perde mais tempo do que ganha (posso estar errado), mas nos projetos nossos aqui, cada um programando em funcionalidades diferentes, deram mais resultados, sim sim, nós já fizemos um teste com pair programming para ver. Acredito que em funcionalidades complexas, onde você não tem nada pronto, onde é um novo mundo que irá entrar, perfeito, pair programming funciona, mas se for alguma funcionalidade que você ja implementou, ou algo que irá fazer um refactor, acredito que duas pessoas seja perca de tempo.

isso tudo IMHO é claro

Sei não, Manchester. As minhas experiências com pair programming foram muito boas. Talvez o tempo para produzir um mesmo código fosse maior, mas a quantidade de bugs para serem consertados foram muito menores do que se eu tivesse produzido o código sozinho. Além do fato de eu ter podido aprender/ensinar bastante durante o tempo em que programei desta forma.

ManchesteR wrote:mas nos projetos nossos aqui, cada um programando em funcionalidades diferentes, deram mais resultados

Isso sim, mas a tua equipe tem que estar em sintonia, cada um tem que saber bem o que esta fazendo.. como se fosse um tipo de futebol, onde se vc simplesmente colocar um monte de fodoes junto, sem treinar, nao vai ser usado todo o potencial, podendo dar problemas..
Mas cada um focado em algo, fazendo bem, eh rula!!

Rafael

Daniel Quirino Oliveira wrote:
Sei não, Manchester. As minhas experiências com pair programming foram muito boas. Talvez o tempo para produzir um mesmo código fosse maior, mas a quantidade de bugs para serem consertados foram muito menores do que se eu tivesse produzido o código sozinho. Além do fato de eu ter podido aprender/ensinar bastante durante o tempo em que programei desta forma.

Como eu disse, depende muito da funcionalidade que você irá implementar...

ManchesteR wrote:só não acho o pair programming muito interessante, mas de resto acho muito boa.

Acho que se tiver uma disparidade muito grande entre os dois programadores, acaba empacando a coisa. Um quer fazer a coisa em um ritmo e o outro "puxa o freio de mão" demais por que pode não estar entendendo patavina. Lógico que é interessante no caso de um ensinar o outro, mas com os prazos "jeitados" que temos hoje é meio complicado.

Notícias, artigos e o maior fórum brasileiro sobre Java