Vixi, deixa eu ficar quieto aqui que conheço um monte também … 
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? 
Não querendo me intrometer, mas já me intrometendo… :lol:
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!!! 8)
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:
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… :roll:
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! :twisted:
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… :roll:
Eu acho que a quantidade de bugs por linhas de código escrito aumenta logaritmicamente com o tamanho do projeto e o número de pessoas envolvidas.
…e aumenta exponencialmente com aumento da complexidade do projeto!(completando o louds)