Hoje, trataremos da metodologia Go Horse que, nos cyber-territórios e entidades ligadas à SIGMA, é um semi-estilo de vida já; aliás é atordoantemente mais divertido. Go Horse é a metodologia de gestão e/ou desenvolvido ágil de projeto (participativo ou não) que se aplica a tudo no universo, sendo atemporal e somente esta metodologia leva a natureza humana em conta, ao contrário das demais metodologias, que são modinhas.

Go Horse pode ser um termo desconhecido para você, leitor, mas certamente você já presenciou ou mesmo integra organizações sob a jurisdição dos códigos de conduta, postura e ética de Go Horse, seja em qual for a área ou situação que tente analisar. Apostaria ainda que você é um horse também.

Para você ter uma ideia do poderio do Go Horse, leitor, saiba que Go Horse é tão poderoso que, quando você opta por NÃO escolher uma metodologia, você escolhe Go Horse, ou melhor, Go Horse escolhe você. Isto acontece porque Go Horse está acima de sua capacidade humana de compreender, lidar e arbitrar. Isto está além de seu arbítrio consciente; e é assim porque Go Horse assim o quer.

Apesar de não parecer, Go Horse é uma metodologia séria usada para lidar e arbitrar com a selvageria das hierarquias do mundo. Go Horse entra em cena quando um projeto já começa atrasado, sem recursos suficientes, sem orçamento real, sem gente capacitada, o sem qualquer possibilidade de postergação, não importando quais sejam as consequências das decisões tomadas ou riscos praticados.

Assim sendo, Go Horse é ubíquo; está em toda parte. Quantas vezes você deixou para fazer uma tarefa ou realizar um projeto no final do prazo de entrega? Pois bem, você foi um horse, e provavelmente ainda é um horse, e, me arisco a afirmar veementemente que você ainda será um horse até o final da sua vida. Eu diria até que você morrer no meio de um processo Go Horse, ou melhor, eu decorrência deste. — Kek

Ainda que Go Horse seja uma metodologia ubíqua e inevitável, esta somente veio a ser descrita na área de programação de computadores, setor produtivo em que Go Horse é praticamente um monopólio. Não adianta questionar, todo programa de computador começa com uns arranjos fuleiros de código feitos da forma mais rápida e “eficiente” para apresentar um resultado. — Normalmente é um “printf(“ok”)”

O método Go Horse prioriza o trabalho sem perda de tempo. Não se perde tempo planejando, discutindo, prevendo futuras falhas, ou pensando. O tempo é muito valioso então é simplesmente fazer o trabalho sem demorar de mais. De curso, o tempo não é arbitrável, então fingimos estar suprimindo ele. — O Tempo e eu lado a lado, como sempre, tornando a vida mais dinâmica e inesperada, ao custo da própria vida, as vezes.

Apesar de o Go Horse ser a metodologia de gestão de recursos e ambientes mais fantástica, estupenda e eficiente que existe, não faltam os seus detratores. Quem nunca teve de interagir com algum colega que, inconformado com o jeito Go Horse de ser do ambiente, tenta (inutilmente) mudar as coisas? É pura perda de tempo tentar fazer algo assim em um ambiente Go Horse porque a metodologia já está inserido na máquina educacional-corporativa.

Aliás, apenas por exposição prolongada com a SIGMA, você se tornará cada vez mais um horse.

Axiomas

Uma pessoa já sabe como funciona o Go Horse, ainda que nunca tenha lido qualquer coisa sobre. Então, listaremos aqui os axiomas, que são como os mandamentos do Go Horse, afim de evitar que as pessoas tenham problemas com o Go Horse, apesar disto ser inevitável em algum momento. Deveria haver um livro na Bíblia sobre o Go Horse. Quem sabe no Novíssimo Testamento…

1 — Pensou, não é Go Horse.

Go Horse 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 resolver um problema: a correta, a errada e a Go Horse, que é igual à errada só que mais rápida.

Go Horse é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece. RAD é coisa de frutinha. Vide axioma 14.

3 — Quanto mais Go Horse você faz, mais precisará fazer.

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

4 — Go Horse é totalmente reativo.

Os erros só existem quando aparecem.

5 — Com Go Horse 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 — Go Horse 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 cometer irregularidades e contravenções.

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

Pra quem usa Go Horse, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor ter um currículo eficiente, ou ter algo pra colocar a culpa.

9 — Seja autêntico, Go Horse 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 Go Horse rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar. Conforme justifica o axioma 8.

11 — Go Horse é 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. Relembre o axioma 4.

12 — Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor Go Horse a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito, como bem cita o axioma 10.

13 — Go Horse é 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 — Go Horse é atemporal.

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

15 — Go Horse nem sempre é POG.

Muitas implementações de programação orientada à gambiarras (POG) exigem um raciocínio muito elevado, Go Horse não raciocina, então Go Horse nem sempre é POG. Reiterando o axioma 1.

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

Caso seus colegas de trabalho usem Go Horse para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Para cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando Go Horse. É a lei do caos!

17 — O Go Horse não é perigoso até surgir um pouco de ordem.

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

Não tente gerenciar o Go Horse, ele é auto-suficiente, como rege o axioma 11, assim como o caos.

18 — O Go Horse é seu brother, mas é vingativo.

Enquanto você quiser, o Go Horse sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando Go Horse e abandoná-lo para utilizar uma metodologia da moda, você vai se fuder gostosin’. O Go Horse não permite refactoring, como incita o axioma 10, e seu novo sistema cheio de frescuras entrará em colapso em meio ao caos que é Go Horse. No entanto, nessa hora, Go Horse (e somente) poderá salvá-lo.

19 — Se estiver funcionando, não toque.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe, como rege o axioma 10. Tempo é a engrenagem que move o Go Horse e qualidade é um detalhe ligeiramente desprezível.

20 — Teste é para os fracos.

Se você meteu a mão num sistema Go Horse, é 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 Go Horse não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando Go Horse são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de perspectiva. 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 projeto.

Nunca ponha a mão num projeto 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.

Saiba mais no portal da metodologia, donde eu catei boa parte do texto; nada mais Go Horse que isso né? Eu exalo Go Horse. Hmkk

 17