eXtreme Go Horse Programming

JavaBaby Membro desde: 18/06/2009 23:38:01 Mensagens: 86 Offline

Ai pessoal,

Já participaram de um projeto que utiliza eXtreme Go Horse Programming?

Se liga só

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar? ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma

.

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás? não pense, faça!

14- XGH é atemporal.

Scrum, XP? tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG?s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma

. Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

[url]Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/[url]

Essa é velha, hein?

JavaBaby Membro desde: 18/06/2009 23:38:01 Mensagens: 86 Offline

ViniGodoy wrote:Essa é velha, hein?

Essa é velha mesmo, mas mesmo assim, parece que empresas insistem em investir nessa metodologia de desenvolvimento.

Essa é velha mesmo, mas mesmo assim, parece que empresas insistem em investir nessa metodologia de desenvolvimento.

Pelo jeito é uma metodologia de sucesso...

Jovem,
Realmente isso é mais velho do que andar pra frente.

Mas infelizmente existem muitos projetos que adotam esta metodologia.
E o mais engraçado quando o cliente reclama de qualidade da entrega, todos ficam supresos .....

Abs,

This message was edited 1 time. Last update was at 03/06/2011 09:56:27

Kanin Dragon wrote:Mas infelizmente existem muitos projetos que adotam esta metodologia.
E o mais engraçado quando o cliente reclama de qualidade da entrega, todos ficam supresos .....

Acho que tenho uma opinião controversa sobre isso...

Para mim a qualidade da entrega depende quase que exclusivamente dos profissionais que desenvolvem.

Já vi equipes sem qualquer metodologia (ou go horse, se preferir), entregar com boa qualidade apenas por que cada um assumia a resposabilidade pelo que fazia.

Pra mim uma boa metodologia é a que não me atrapalhe.

JavaBaby Membro desde: 18/06/2009 23:38:01 Mensagens: 86 Offline

AbelBueno wrote:

Kanin Dragon wrote:Mas infelizmente existem muitos projetos que adotam esta metodologia.
E o mais engraçado quando o cliente reclama de qualidade da entrega, todos ficam supresos .....

Acho que tenho uma opinião controversa sobre isso...

Para mim a qualidade da entrega depende quase que exclusivamente dos profissionais que desenvolvem.

Já vi equipes sem qualquer metodologia (ou go horse, se preferir), entregar com boa qualidade apenas por que cada um assumia a resposabilidade pelo que fazia.

Pra mim uma boa metodologia é a que não me atrapalhe.

Nossa....

Me da medo isso...

Virtual Machine Man Membro desde: 26/05/2009 15:57:49 Mensagens: 707 Offline

é ainda existem pessoas que usam =), já usei e me arrependo ate hoje pq vou ter que refazer o projeto do zero, não entendo nem o nome dops métodos asuhauhsuah, Documentação -5, Design Pattern -5, projeto viveu 24 hras depois morreu.

haushua

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

essa é mais antiga que meu tataravo... porem é usada pela grande maioria das empresas...

rafaelpiton wrote:

AbelBueno wrote:

Kanin Dragon wrote:Mas infelizmente existem muitos projetos que adotam esta metodologia.
E o mais engraçado quando o cliente reclama de qualidade da entrega, todos ficam supresos .....

Acho que tenho uma opinião controversa sobre isso...

Para mim a qualidade da entrega depende quase que exclusivamente dos profissionais que desenvolvem.

Já vi equipes sem qualquer metodologia (ou go horse, se preferir), entregar com boa qualidade apenas por que cada um assumia a resposabilidade pelo que fazia.

Pra mim uma boa metodologia é a que não me atrapalhe.

Nossa....

Me da medo isso...

Isso me dá medo também. Parece papo de gerente quetendo te convencer a ser herói.

JavaEvangelist Membro desde: 30/04/2007 07:43:01 Mensagens: 424 Offline

Essa metodologia é a mais verdadeira que tem.

Ela já me salvou uma vez.

Certa vez eu estava em um projeto nojento, mas nojento como provavelmente nunca mais verei na vida, uma aplicação muito mal desenhada, tudo mal implementado, más práticas, enfim, um terror. O cliente ficava em outro estado, as vezes eu ia para lá e ficava dias debugando aquela merda para entender como as coisas funcionavam (e ao mesmo tempo ficava imaginando como um dia pensaram em fazer aquilo daquele jeito).

Eu tentava fazer tudo certo, as vezes levavam horas para implementar uma solução para um problema fácil, de tão engessado que o sistema estava. Era realmente remar contra a maré, e por mais que eu tentava atuar corretamente para salvar o projeto, só trazia mais problemas.

Ai uma vez recebi um e-mail com o link para esse site, li tudo e fiquei uma meia hora rindo e vendo como aquilo tudo fazia sentido. Eu parei de me sentir culpado ou chateado por carregar aquele piano nas costas e corrigir cagada dos outros. Aquilo foi uma libertação, dali pra frente atuei com a metodologia xGH no projeto e desde então já colocamos mais 2 releases em produção.

Vou sair de férias e na volta devo voltar a atuar nesse projeto mais uma vez, e vai ser xGH na veia, foda-se e não sinto a menor culpa por isso, nos outros projetos, os decentes, atuo de maneira decente. Agora em projetos irreversíveis, não vou mais ficar perdendo os cabelos por conta de idéias brilhantes dos outros que resolvem reinventar a roda e coisas do tipo para empurrar projeto mais caro para cliente.

Virtual Machine Man Membro desde: 04/08/2010 09:37:57 Mensagens: 543 Offline

josenaldo wrote:Isso me dá medo também. Parece papo de gerente quetendo te convencer a ser herói.

Na verdade é papo de desenvolvedor cansado de trabalhar com gerentes que enchem a equipe de júnior/estagiário e diz garantir a qualidade do projeto por que utiliza a metodologia XYZ.

Eu prefiro trabalhar com uma equipe de bons profissionais (seniors) sem uma metodogia formal do que num processo organizado lotado de gente fraca ou muito inexperiente.

Lembrando apenas, essa é apenas minha opinião.

Virtual Machine Man Membro desde: 26/05/2009 15:57:49 Mensagens: 707 Offline

AbelBueno wrote:

josenaldo wrote:Isso me dá medo também. Parece papo de gerente quetendo te convencer a ser herói.

Na verdade é papo de desenvolvedor cansado de trabalhar com gerentes que enchem a equipe de júnior/estagiário e diz garantir a qualidade do projeto por que utiliza a metodologia XYZ.

Eu prefiro trabalhar com uma equipe de bons profissionais (seniors) sem uma metodogia formal do que num processo organizado lotado de gente fraca ou muito inexperiente.

Lembrando apenas, essa é apenas minha opinião.

Não acho que só pq a pessoa é inexperiente ela não consegue seguir uma metodologia ou pq ela é experiente ela segue a metodologia.!

JavaBaby Membro desde: 18/06/2009 23:38:01 Mensagens: 86 Offline

josenaldo wrote:

rafaelpiton wrote:

AbelBueno wrote:

Kanin Dragon wrote:Mas infelizmente existem muitos projetos que adotam esta metodologia.
E o mais engraçado quando o cliente reclama de qualidade da entrega, todos ficam supresos .....

Acho que tenho uma opinião controversa sobre isso...

Para mim a qualidade da entrega depende quase que exclusivamente dos profissionais que desenvolvem.

Já vi equipes sem qualquer metodologia (ou go horse, se preferir), entregar com boa qualidade apenas por que cada um assumia a resposabilidade pelo que fazia.

Pra mim uma boa metodologia é a que não me atrapalhe.

Nossa....

Me da medo isso...

Isso me dá medo também. Parece papo de gerente quetendo te convencer a ser herói.

Bah falou tudo!

This message was edited 1 time. Last update was at 03/06/2011 13:12:28

Eu respiro XGH dentro do Banco!

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