http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net , 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/]]> http://www.guj.com.br/prepost/7205/37098/qual-a-sua-metodologia-de-trabalho http://www.guj.com.br/prepost/7205/37098/qual-a-sua-metodologia-de-trabalho GMT ]]> http://www.guj.com.br/prepost/7205/37101/ http://www.guj.com.br/prepost/7205/37101/ GMT

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.]]> http://www.guj.com.br/prepost/7205/37104/ http://www.guj.com.br/prepost/7205/37104/ GMT http://www.guj.com.br/prepost/7205/37105/ http://www.guj.com.br/prepost/7205/37105/ GMT
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.]]> http://www.guj.com.br/prepost/7205/37106/ http://www.guj.com.br/prepost/7205/37106/ GMT http://www.guj.com.br/prepost/7205/37107/ http://www.guj.com.br/prepost/7205/37107/ GMT
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]]> http://www.guj.com.br/prepost/7205/37108/ http://www.guj.com.br/prepost/7205/37108/ GMT Afinal, por que vocês não gostam de pair programming?]]> http://www.guj.com.br/prepost/7205/37109/ http://www.guj.com.br/prepost/7205/37109/ GMT http://www.guj.com.br/prepost/7205/37110/ http://www.guj.com.br/prepost/7205/37110/ GMT 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]]> http://www.guj.com.br/prepost/7205/37112/ http://www.guj.com.br/prepost/7205/37112/ GMT
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 ]]> http://www.guj.com.br/prepost/7205/37113/ http://www.guj.com.br/prepost/7205/37113/ GMT
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 [/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.]]> http://www.guj.com.br/prepost/7205/37114/ http://www.guj.com.br/prepost/7205/37114/ GMT
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]]> http://www.guj.com.br/prepost/7205/37115/ http://www.guj.com.br/prepost/7205/37115/ GMT 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...]]> http://www.guj.com.br/prepost/7205/37116/ http://www.guj.com.br/prepost/7205/37116/ GMT 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.]]> http://www.guj.com.br/prepost/7205/37169/ http://www.guj.com.br/prepost/7205/37169/ GMT 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. ]]> http://www.guj.com.br/prepost/7205/37171/ http://www.guj.com.br/prepost/7205/37171/ GMT [/quote]

...e quem, nesse caso, pensa a longo prazo no Brasil?

Ta certo, podemos ate arrumar alguns exemplos... mas, mesmo assim, faz feio ]]> http://www.guj.com.br/prepost/7205/37172/ http://www.guj.com.br/prepost/7205/37172/ GMT 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.]]> http://www.guj.com.br/prepost/7205/37175/ http://www.guj.com.br/prepost/7205/37175/ GMT [/quote]

...e quem, nesse caso, pensa a longo prazo no Brasil?

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).]]> http://www.guj.com.br/prepost/7205/37177/ http://www.guj.com.br/prepost/7205/37177/ GMT 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. ]]> http://www.guj.com.br/prepost/7205/37178/ http://www.guj.com.br/prepost/7205/37178/ GMT Vixi, deixa eu ficar quieto aqui que conheço um monte também ... ]]> http://www.guj.com.br/prepost/7205/37181/ http://www.guj.com.br/prepost/7205/37181/ GMT Vixi, deixa eu ficar quieto aqui que conheço um monte também ... [/quote]

Concordo que nao precisamos dar nomes aos bois magros, mas encher a bola de quem faz a coisa direito vale a pena. Alguem tem exemplos de empresas onde adotar bem uma metodologia significou em um aumento significativo na qualidade e produtividade? ]]> http://www.guj.com.br/prepost/7205/37185/ http://www.guj.com.br/prepost/7205/37185/ GMT

Infelizmente não conheço tal empresa, mas tenho uma dúvida, em termos de mercado, qual metodologia é mais usada, ou qual tem uma procura maior por profissionais que a conhece

Bem, não sei se o objetivo do tópico é exatamente esse ou simplesmente conhecer a preferência do pessoal, me perdoem se estiver confundindo as bolas, ok?? Mas fica aí a minha dúvida.

Falow!!! ]]> http://www.guj.com.br/prepost/7205/37246/ http://www.guj.com.br/prepost/7205/37246/ GMT [/quote]

Talvez os resultados desta votação digam de uma forma ou de outra qual a metodologia mais utilizada. Mas, se vc está procurando aprender alguma baseando-se nessa informação, meu conselho aqui é: aprenda todas, goste de uma delas e se aprofunde, mas não simplesmente descarte as "perdedoras" na sua preferência ]]> http://www.guj.com.br/prepost/7205/37249/ http://www.guj.com.br/prepost/7205/37249/ GMT [/quote]

Ok, conselho anotado e muito provavelmente será seguido ]]> http://www.guj.com.br/prepost/7205/37253/ http://www.guj.com.br/prepost/7205/37253/ GMT http://www.guj.com.br/prepost/7205/37258/ http://www.guj.com.br/prepost/7205/37258/ GMT
Outro tema que foi pouco discutido aqui é o de fazer testes unitários. Mas isso fica pra outro tópico, pq acho que a discussão é quente... vou deixar só uma perguntinha filosófica aqui: se um determinado software tem um bug, e não nenhuma teste para demonstrá-lo, esse bug existe?]]> http://www.guj.com.br/prepost/7205/37260/ http://www.guj.com.br/prepost/7205/37260/ GMT [quote]se um determinado software tem um bug, e não nenhuma teste para demonstrá-lo, esse bug existe?[/quote]

CV, todo programa tem bug,vc q não testou ele o suficiente...

Agora falando sério,se vc passa o programa num teste de unidade,sem problemas,num teste de estresse,sem problemas,segue aquele zilhão de protocolos e testes de componentes,e o programa passa.das duas uma:
Considerando que há erros;ou a equipe de testes é fraca(e a bateria tb),ou eh um white fly error...ele existe,ninguém viu ninguém vê,só Einstein resolve...
Claro q programas com zilhões de linhas de código(tipo o windows) que tem milhares de programadores envolvidos(tipo windows) cada um com uma metodologia de programar diferente(tipo windows,tô pegando no pé...),erros são pra-lá de comuns....e esperados!Mas aplicações pequenas,de complexidade moderada,dificilmente são perdoados... ]]> http://www.guj.com.br/prepost/7205/37281/ http://www.guj.com.br/prepost/7205/37281/ GMT ]]> http://www.guj.com.br/prepost/7205/37287/ http://www.guj.com.br/prepost/7205/37287/ GMT
Com certeza vc entendeu direito...quis dizer q aplicações de complexidade muito inferior,muito menos linhas de código,dificilmente eh perdoado(...) em algumas empresas,se vc erra um campinho de validação de Cpf,já te chamam pro pau(...),errar eh humano(acertar eh mulçumano-piada infame),e qto mais banal a tarefa,ás vezes maior a chance de erros...pena q os empregadores querem humanos-xeon,365x24x7,e esquecem q são só humanos... ]]> http://www.guj.com.br/prepost/7205/37415/ http://www.guj.com.br/prepost/7205/37415/ GMT http://www.guj.com.br/prepost/7205/37437/ http://www.guj.com.br/prepost/7205/37437/ GMT http://www.guj.com.br/prepost/7205/37445/ http://www.guj.com.br/prepost/7205/37445/ GMT