De certa forma, eu já até faço idéia do resultado dessa votação :roll:, 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 :lol: , 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).
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
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…
Afinal, por que vocês não gostam de pair programming?[/quote]
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
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.[/quote]
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 :lol:
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.[/quote]
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 :lol:[/quote]
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.
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
[quote=“Daniel Quirino Oliveira”]
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.[/quote]
Como eu disse, depende muito da funcionalidade que você irá implementar…
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.
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.[/quote]
Bom, se você pensar a curto prazo, talvez você esteja certo. Mas, a médio e longo prazo, sua equipe passa a ser mais homogênea e a qualidade muito maior.
…e quem, nesse caso, pensa a longo prazo no Brasil? :evil:
Ta certo, podemos ate arrumar alguns exemplos… mas, mesmo assim, faz feio 
[quote=“TaQ”]
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.[/quote]
Provavelmente com uma disparidade muito grande o que sabe pouco, trabalhando sózinho, provavelmente vai ter muito problema se precisar utilizar algo que escrito pelo que sabe muito, ou seja, vai causar tanto problema quanto usando pair-programming.
Moral da historia, esse cara já deveria ter passado no rh.
Pair programming funciona muito bem quando você tem diferenças de conhecimento, mas não de inteligencia.
…e quem, nesse caso, pensa a longo prazo no Brasil? :evil:
Ta certo, podemos ate arrumar alguns exemplos… mas, mesmo assim, faz feio [/quote]
Concordo, mas, isso não depende da metodologia usada, mas é questão de estratégia de empresa. E a empresa que não pensa na evolução contínua do seus profissionais nunca vai deixar de ser medíocre (poderia citar alguns nomes de empresas assim, mas é totalmente anti-ético).
[quote=“louds”]
Moral da historia, esse cara já deveria ter passado no rh.
Pair programming funciona muito bem quando você tem diferenças de conhecimento, mas não de inteligencia.[/quote]
Agora se ele for aqueles tipos que tem muito Q.I. (quem indicou) isso pode ser um problema.