Um amigo aqui do trabalho me indicou uma nova/velha metodolodia de trabalho muito interessante.
E o mais interessante ainda, é que, enquanto estava lendo, fui percebendo que já utilizamos ela a muito tempo e não sabíamos.
Segue abaixo os princípios do XGH – Extreme Go Horse:

eXtreme Go Horse (XGH)

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

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

Fonte: http://gohorseprocess.wordpress.com/

Navegando… navegando… encontrei o blog do Igo Coelho e achei um artigo de uma tradução feita do Coding Horror, muito bom.

Segue abaixo:

Jerry Weinberg: Os 10 Mandamentos da Programação sem Ego

1. Entenda e aceite que você irá cometer erros;
2. Você não é o seu código;
3. Não importa quanto “Karatê” você sabe, sempre haverá alguém que sabe mais que você;
4. Não reescreva código sem orientação;
5. Trate as pessoas que sabem menos que você com respeito, consideração e paciência;
6. A única constante no mundo é a mudança;
7. A verdadeira autoridade nasce do conhecimento, não da posição;
8. Lute pelo que acredita, mas aceite a derrota com elegância;
9. Não seja “o cara na sala”;
10. Critique o código ao invés da pessoa – seja gentil com o programador, não com o código.

Dare Obasanjo: Os 10 Sinais de Que Seu Projeto Está Condenado

1. Tentar fazer muita coisa na primeira versão;
2. Criar uma funcionalidade crítica usando uma tecnologia não comprovada;
3. Competir com um projeto interno que já existe e que tem ótimo retorno ou tem patrocinadores poderosos;
4. A equipe tem menos pessoas que o necessário;
5. “Problemas complexos requerem soluções complexas”;
6. Prazos irreais;
7. Mudanças descontroladas no escopo do projeto;
8. Sindrome do segundo sistema “Second System Syndrome”;
9. Não ter estratégia de entrada no mercado;
10. Ficar travado em um problema que você não sabe como resolver.

Omar Shahine: As 10 Dicas Para Trabalhar na Microsoft(ou em qualquer outro lugar)

1. Processo não é substituto para raciocínio;
2. Saia do seu escritório;
3. Use seu produto(o que seus clientes irão usar);
4. Conserte as coisas que estão quebradas ao invés de reclamar por elas estarem quebradas. Ações falam mais que suas reclamações;
5. Faça um problema difícil parecer fácil. Não faça problemas fáceis parecerem difíceis;
6. Use a ferramenta de comunicação correta para o serviço;
7. Aprenda a cometer erros;
8. Mantenha as coisas simples;
9. Adicione valor sempre;
10. Use o produto dos outros.

Michael McDonough: As 10 Coisas que Nunca me Ensinaram na Escola de Design

1. Talento é um-terço na equação do sucesso;
2. 95 por cento de qualquer profissional criativo é trabalho;
3. Se tudo é igualmente importante, então nada é muito importante;
4. Não pense demais sobre um problema;
5. Comece com o que você sabe; então remova o que você não sabe;
6. Não esqueça seu objetivo;
7. Quando você joga seu peso para os lados, você geralmente cai da balança;
8. A estrada para o inferno está cheia de boas intenções; ou, nenhuma boa ação sai impune;
9. Tudo isto vai aparecer no final;
10. O resto do mundo importa.

Andres Taylor: As 10 Coisas que Aprendí em Dez Anos como Proffisional em Desenvolvimento de Software.

1. Orientação a objetos é mais difícil do que você pensa;
2. A parte difícil no desenvolvimento de software é a comunicação;
3. Aprenda a dizer não;
4. Se tudo é igualmente importante, então nada é importante;
5. Não pense demais sobre um problema;
6. Mergulhe realmente fundo em algo, mas não fique preso;
7. Aprenda sobre as outras partes da máquina de desenvolvimento de software;
8. Seus colegas são seus melhores professores;
9. Tudo isto vai terminar no programa em produção;
10. Algumas pessoas são idiotas.