eXtreme Go Horse Process (XGH)

Atenção! Esse post contém altas doses de ironia. xD

Todo gerente ou desenvolvedor já ouviu falar nas famosas metodologias ágeis de desenvolvimento, como Scrum e XP, muito praticadas e difundidas em várias empresas de software.

É por isso que hoje venho compartilhar algo que não se ensina na faculdade, na graduação ou no mestrado, muito menos no curso técnico. É uma coisa que já nasce no instinto do programador, em suas primeiras linhas de código. Estou falando da Metodologia de Desenvolvimento GHP (Go Horse Process), também chamada, em sua versão extrema, de eXtreme Go Horse Process (XGH).

Se você não sabe o que é uma metodologia de desenvolvimento, não se preocupe: as dicas abaixo vão te deixar totalmente preparado para agilizar e “disciplinar” sua empresa. Vamos esquecer que já ouvimos falar em PMBOK ou PMI e vamos falar sobre gerenciar de forma clara e objetiva, simples e direta, sem blábláblá. Vamos falar de GHP!

GHP MANIFESTO X AGILE MANIFESTO

O eXtreme Go Horse Manifesto é uma resposta ao Agile Manifesto. Compare as duas abordagens e constate a superioridade do GHP sobre o monte de baboseiras pregadas pelos nerds do Agile.

Conheça o eXtreme Go Horse Manifesto:

Ou seja, valorizamos os itens da coluna em verde, e não vemos valor algum nas colunas em vermelho.

GRANDES AXIOMAS DO XGH

Com vocês, os 22 axiomas do 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 três 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 vai precisar fazer.

Para cada problema resolvido usando XGH, mais uns sete são criados. E todos eles vão ser resolvidos da forma XGH, que 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 é 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 vai 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.

Para quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia em que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo para 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 é 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 vai 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 a coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução vai 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, ele sempre foi e sempre vai ser usado por aqueles que desprezam a qualidade.

15. XGH nem sempre é POG.

Muitas POGs 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! Para cada Design Pattern que você usar corretamente, seus colegas vão gerar dez 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 pôr ordem no XGH (vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto vai fazer com que o projeto afunde mais rápido ainda (vide Axioma 8). Não tente gerenciar o XGH, ele é autossuficiente (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ê se ferra. O XGH não permite refactoring (vide axioma 10) e seu novo sistema cheio de frescurites vai entrar em colapso. E nessa hora somente o XGH vai poder salvá-lo.

19. Se tiver funcionando, não encosta 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 para quê? 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 em uma classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco vai afundar! Nesse caso, utilize o Axioma 8.

POR QUE USAR XGH?

Se você leu todos os mandamentos, com certeza irá se perguntar: “Mas por que usar GHP? Qual a vantagem?” Bem, não pense que só você tem esses questionamentos. Isso é normal quando estamos começando em uma tecnologia nova, por isso é que também vou mostrar algumas dúvidas de profissionais:

Existe a possibilidade de desenvolver uma carreira promissora como um Gerente de Projetos Go Horse?

Sim! A maioria das organizações usa o Go Horse. Mas cuidado: para ser bem-sucedido na carreira, não tente adotar o Go Horse em uma organização que aplica o blábláblá do PMI. Veja este exemplo real: Um certo gerente de uma certa empresa encontrou alguns problemas durante um projeto. Para resolvê-los, aplicou todas as técnicas do Go Horse, ou seja, pediu mais verba ao chefe quando o dinheiro acabou (em torno de 50%), mais prazo (11 meses), enrolou os superiores quanto ao escopo e entregou o projeto. O que aconteceria com esse gerente em uma empresa dominada pelos malas do PMI? Seria demitido. No entanto, como o Go Horse era a prática adotada pela organização, esse gerente virou diretor!

Qual a metodologia mais eficiente? Go Horse ou PMBOK?

Ora, essa é fácil: Go Horse, claro! Mais da metade dos projetos gerenciados com as técnicas propostas pelos burocratas do PMI falham — isto porque o PMBOK diz que um projeto só é bem-sucedido quando entregue dentro do prazo, cumprindo o escopo e respeitando as restrições orçamentárias. O Go Horse, por outro lado, é contrário a esse monte de regras. Como a ideia é ir fazendo o projeto e pedir dinheiro à medida em que for preciso, fazendo o escopo que der na telha ao longo do projeto, nunca vai ter falha — afinal, não se perde tempo com planejamento. Ou seja, para o Go Horse, projeto de sucesso é projeto entregue! Não é fantástico?

Existe prova de certificação Go Horse?

Hein?

O PMI tem o seu código de ética. E o Go Horse?

O Go Horse também. Leia As 48 leis do Poder, de Robert Greene e Jost Elffers.

Como faço para descobrir se minha empresa usa Go Horse?

Se você não sabe qual a metodologia utilizada pela sua empresa, então com certeza ela usa Go Horse.

Referências:

http://gohorseprocess.wordpress.com

http://www.gohorseprocess.com.br/

http://www.mochilabinaria.com.br/

Fonte: https://www.concrete.com.br/2017/08/21/extreme-go-horse-xgh/