Qual a sua metodologia de trabalho?

TaQ wrote:

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.

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.

Daniel Quirino Oliveira wrote: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?

Ta certo, podemos ate arrumar alguns exemplos... mas, mesmo assim, faz feio

TaQ wrote:
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.

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.

cv wrote:

Daniel Quirino Oliveira wrote: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?

Ta certo, podemos ate arrumar alguns exemplos... mas, mesmo assim, faz feio

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).

louds wrote:
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.

Agora se ele for aqueles tipos que tem muito Q.I. (quem indicou) isso pode ser um problema.

Daniel Quirino Oliveira wrote: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).

Vixi, deixa eu ficar quieto aqui que conheço um monte também ...

TaQ wrote:

Daniel Quirino Oliveira wrote: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).

Vixi, deixa eu ficar quieto aqui que conheço um monte também ...

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?

Não querendo me intrometer, mas já me intrometendo...

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!!!

jc_oz wrote: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

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

cv wrote: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

Ok, conselho anotado e muito provavelmente será seguido

Bom, acho que já batemos bastante na tecla do "pair programming", mas XP não é só isso. O que vocês acham dos outros "dogmas" do XP, como refactoring contínuo, design simples, story cards, etc...?

Pra falar a verdade, eu não sei nem como alguem consegue trabalhar sem refactoring contínuo (sem passar o tempo todo sem pelo menos dar uma "embelezada" em um código que foi escrito anteriormente)...

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?

cv disse:

se um determinado software tem um bug, e não nenhuma teste para demonstrá-lo, esse bug existe?

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...

Ou seja, qualquer aplicacao menor que o Windows, e de complexidade menor que um sistema operacional, não pode ser perdoada por ter bugs?

Cv não deturpe minhas palavras!

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...

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