Bruno Noriller – Programador entre outras coisas
Sim, vamos falar um pouco sobre ser ágil e a definição brasileira do estado atual gerado ágil chamado metodologia “eXtreme Go Horse”.
Os equívocos
A primeira coisa é tirar os equívocos comuns do caminho.
O Agile está indo rápido
Até agora, todos nós (devemos) saber que o ágil não é sobre ser mais rápido. Trata-se de entregar valor mais cedo e de forma constante e ser capaz de reagir e mudar de rumo mais cedo.
Sprint está fazendo tudo no horário
Então… você está dizendo que o ágil não é sobre ser rápido, mas que também significa ter… sprints?
Pode ter sido um termo infeliz usado pelos desenvolvedores do Scrum, mas certamente não ajuda com todo o “ágeo é ser rápido” que as pessoas gostem de pensar.
Sprints, no entanto, são apenas uma caixa de tempo para uma certa quantidade de trabalho a ser feito.
O problema
Os executivos pressionam por ágil e scrum porque pensam em ser rápidos, sprints!
Mas o maior problema é que fazer software não é um sprint, é uma maratona.
E a menos que você não seja humano, você sabe que não pode correr uma maratona. É uma reallypéssima ideia.
Diabos! A maioria das pessoas não consegue nem mesmo correr uma corrida curta. E também estou falando de software.
O resultado das pessoas
Burnout (em inglês). Simples e simples, a profissão perde muita gente boa por causa do esgotamento.
Não deve ser confundido com “queima” (gráficos), também do scrum, mas de alguma forma isso não gera qualquer confusão das mesmas pessoas que esperam cada vez mais dos desenvolvedores.
Em um ponto, as empresas tinham muitos desenvolvedores, muitos fazendo basicamente recursos de bloatware e “não gerando valor suficiente”. Então as demissões em massa vieram e foram (ou ainda estão indo) e agora você tem desenvolvedores ainda mais sobrecarregados.
O resultado do software
Como as pessoas são pressionadas a ir rápido e, em seguida, mais rápido, a qualidade cai, e “rápido e sujo” se torna a norma.
Não há tempo para testes, não há tempo para a qualidade do código, ou código limpo e boas práticas, mas sempre há tempo e horas extras para corrigir bugs.
Forneça software não rápido, mas com consistência
A primeira coisa que as pessoas veem em novas estruturas é o quão rápido elas podem fazer um “aptapé” … mas essa não é a realidade para a maioria de nós.
Go Horsing rápido e sujo para fazer uma grande tigela de massa lamacenta é ok para um MVP, projeto lateral ou projeto de descarte. Mas na maioria das vezes você estará trabalhando por meses a fio em algo.
O que importa fazer uma coisa rápido e depois desacelerar em cada novo recurso até que você salte do navio (axioma XGH 8) ou decida reescrever a coisa toda (veja o axioma XGH 10).
XGH: eXtreme Go Cavalo
Como eu estava escrevendo este post, chegou à minha atenção que o XGH é comumente conhecido apenas por desenvolvedores brasileiros, mas não o suficiente em todo o mundo.
Isso foi feito por quem sabe quando, por quem sabe quem, é um pouco desatualizado na escrita (vou refatorar conforme necessário), mas como você verá … é atemporal (veja axioma 14) e relevante para o que eu estava dizendo.
Isenção de responsabilidade: Esta é, basicamente, uma lista de “não fazer”. É engraçado como um meme, mas como eu gosto de dizer: se tudo o que você faz é coisa de memes… então sua vida é uma piada.
Havia algumas traduções por aí, mas eu as traduzi aqui tentando atualizar as coisas para fazer mais sentido hoje.
Aproveite, mas não siga. (pequena nota: as pessoas geralmente apenas leem XGH como “go horse”)
Manifesto eXtreme “Go Horse”:
1. Se você tivesse que pensar, não é XGH.
No XGH você não pensa, você faz a primeira coisa que vem à mente. Não há segunda opção, a única opção é a mais rápida.
2. Existem três maneiras de resolver um problema: o certo, o errado e o XGH, que é como o errado, mas mais rápido.
O XGH é mais rápido do que qualquer outra metodologia de desenvolvimento de software que você conhece. (ver axioma 14).
3. Quanto mais XGH você fizer, mais você precisará fazer.
Para cada problema resolvido usando XGH, cerca de 7 serão criados. Mas todos serão resolvidos usando o XGH. XGH tende a infinito.
4. XGH é completamente reativo.
Erros só existem quando eles vêm à tona.
5. O XGH aceita tudo.
Resolveu o problema? – Compilado? Comprometa-se e é isso.
6. Sempre comprometa antes de atualizar.
Se a merda acontecer, a tua parte estará sempre correcta… e os teus colegas podem foder-se.
7. XGH não tem prazo.
Os prazos estabelecidos pelo seu cliente são meros detalhes. Você sempre será capaz de implementar TUDO no tempo determinado (mesmo que envolva o acesso ao banco de dados com um script obscuro).
8 – O que se cal e o 8. Esteja preparado para pular do navio quando ele começar a afundar… ou culpar alguém ou algo mais.
Para aqueles que usam XGH, um dia o navio afundará. Quanto mais o tempo passa, mais o sistema se torna um monstro. No dia em que a casa cai, é melhor ter seu LinkedIn atualizado ou ter algo para culpar.
9. Seja autêntico, XGH não respeita os padrões.
Escreva o código como quiser, se ele resolver o problema, commit e é isso.
10. Não há refatoração, apenas retrabalho.
Se a merda acontecer, refaça um XGH rápido que resolva o problema. O dia em que o retrabalho envolve reescrever toda a aplicação, pular o navio, o barco afundará (veja axioma 8).
11. XGH é completamente anárquico.
A figura de um gerente de projeto é completamente descartável. Não há dono, todo mundo faz o que quer quando surgem problemas e requisitos (ver axioma 4).
12 – O que se refere. Sempre iluda-se com promessas de melhoria.
Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor do XGH a não sentir remorso ou culpa pela merda que fizeram. Claro, a refatoração nunca será feita (ver axioma 10).
13 – O que se refere (em inglês). XGH é absoluto, não se apega a coisas relativas.
Tempo e custo são absolutos, a qualidade é totalmente relativa. Nunca pense em qualidade, apenas no menor tempo que a solução pode ser implementada, na verdade… não pense, apenas faça!
14. XGH é intemporal.
Scrum, XP… tudo isso é apenas uma moda passageira. XGH não se apega às modas do momento, isso é para os fracos. XGH sempre foi e sempre será usado por aqueles que desconsideram a qualidade.
15. XGH nem sempre é programação orientada para soluções alternativas.
Muitas Programações Orientadas para Trabalhar e Opções exigem um nível muito alto de pensamento, mas o XGH não pensa (veja axioma 1).
Nota do tradutor: No original, ele usa Programação Orientada à Gâmbia. Desde que eu entendo que algumas pessoas saberão o que é gambiarra … é um termo mais abrangente do que apenas “hack” ou “workaround”.
16. Não tente nadar contra a maré.
Se seus colegas usam XGH para programação e você é um stickler que gosta de fazer as coisas corretamente, esqueça! Para cada Padrão de Design que você usa corretamente, seus colegas irão gerar 10 vezes mais código podre usando XGH.
17 – Sim. XGH não é perigoso até que uma pequena ordem surge.
Este axioma é muito complexo, mas assume que o projeto usando XGH está no meio do caos. Não tente adicionar ordem no XGH (veja axioma 16), é inútil e você pode perder um tempo precioso. Isso fará com que o projeto afunde ainda mais rápido (ver axioma 8). Não tente gerenciar XGH, é auto-suficiente (ver axioma 11), assim como o caos.
18. XGH é seu aliado, mas é vingativo.
Enquanto você quiser, XGH estará sempre do seu lado. Mas cuidado, não abandone. Se você iniciar um sistema usando o XGH e abandoná-lo para usar uma metodologia moderna, você está fodido. O XGH não permite refatoração (veja axioma 10), e seu novo sistema cheio de babados entrará em colapso. E, nesse momento, apenas XGH pode salvá-lo.
19. Se estiver funcionando, não toque nele.
Nunca mude, e muito menos questione, código de trabalho. Isso é uma perda de tempo, especialmente porque a refatoração não existe (ver axioma 10). O tempo é o equipamento que move o XGH e a qualidade é um detalhe insignificante.
20 anos. O teste é para os fracos.
Se você colocou as mãos em um sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, por que testar? O teste é uma perda de tempo, se o código for compilado, isso é suficiente.
21 – Sim. Acostuma-se com a sensação de fracasso iminente.
Fracasso e sucesso sempre andam de mãos dadas, e em XGH não é diferente. As pessoas muitas vezes pensam que as chances de um projeto falhar usando XGH são sempre maiores do que ser bem sucedido. Mas o sucesso e o fracasso são uma questão de perspectiva. O projeto foi pelo ralo, mas você aprendeu alguma coisa? Então foi um sucesso para você!
22 – Sim. O problema é apenas seu quando seu nome está na culpa.
Nunca coloque a mão em um arquivo cujo autor não é você. Se um membro da equipe morrer ou ficar doente por muito tempo, o barco afundará! Neste caso, use o axioma 8.
23 – Sim. Mais é mais.
Com o XGH, você prospera na duplicação de código – a qualidade do código não importa, e não há tempo para abstrações, revisões de código ou refatoração. O tempo é essencial, então copie e cole rapidamente!
24. O código é a documentação.
No XGH, o código é a única documentação necessária. Comentários e documentação adicional são apenas uma perda de tempo. Se alguém não consegue descobrir como o código funciona, não deve estar trabalhando nele (veja axioma 20).
25 – Sim. A segurança não importa.
No XGH, a segurança é um detalhe secundário. É uma perda de tempo para implementar uma segurança robusta (ver axiomas 5 e 7). Confie na sorte, na falta de interesse dos hackers e no axioma 8.
Fonte: Medium