Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

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

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/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

Anúncios

É melhor focar no problema? ou na solução?

Cabra-cega – Imagem Retirada de http://fadadacaixinhademusica.blogspot.de/

Cabra-cega é uma brincadeira de criança onde alguém coloca uma venda nos olhos e fica com uma vara na mão para tentar acertar um vaso de barro (cheio de doces e gostosuras) e quebrá-lo, dessa forma não só você ganha os doces, quanto todos ao seu redor tb correm para os doces e assim todos saem ganhando! Não sei no restante do Brasil, mas pelo menos em Recife essa é uma brincadeira bem comum. O detalhe dessa brincadeira é que todos os outros ao seu redor ficam dando dicas apra vocês chegar mais perto, e eventualmente acertar o vaso.

Trazendo isso para nossa realidade de TI, um ponto que venho percebendo com uma certa frequência  é que geralmente estamos fechando projetos e contratos onde nosso cliente chega até nós com uma “solução” para o problema dele, e nós geralmente vamos direto atacar essa pseudo-solução! Isso acontece mais frequentemente em casos onde o cliente tem um certo conhecimento de TI, de desenvolvimento de software, então ele já chega com a solução bolada na sua cabeça! E como cada vez mais temos gente que entende [um pouco que seja] de TI, temos essa situação acontecendo cada vez mais.

Me sinto um pouco jogando cabra-cega. Estamos lá, escutando as dicas e as direções dos outros, mas não sabemos exatamente ONDE está o problema! Estamos com uma venda nos olhos tentando caminhar na direção que os outros estão gritando! E eis que chega o grande conselho desse post (que até parece um pouco óbvio):

Tire a venda dos olhos!!

Faça isso, por favor! Procure entender sempre o problema que está por trás de uma solução proposta, entenda o porquê por trás daquilo e procure identificar outras possíveis saídas para aquele problema. Talvez a solução proposta inicialmente pelo cliente seja realmente a melhor, mas talvez seja a pior também. E você só vai saber se tirar a venda dos olhos! TI é pensar! Muitas vezes somos pagos não para implementar algo para o cliente, mas para PENSAR na situação dele e identificar saídas viáveis!

Vale salientar que isso se aplica a diversos contextos dentro do desenvolvimento de projetos, e ainda mais, se aplica a diversas outras áres além de TI!

Cargo cult, eXtreme go horse e afins

Depois de alguns anos escrevendo código, e também, observando códigos de outras pessoas, meus códigos antigos e código legado percebi alguns comportamentos e padrões entre o aptidão e/ou tempo de experiência X design do código das pessoas.

Investigando esses padrões, consegui entender melhor os “porquês” da incidência, em projetos grandes e bem financiados, de fenômenos como Cargo cult, eXtreme go horse, programação orientada a gambiarra e afins.

Contextualizando – Cargo Cult, descrito por Steven C. McConnell no livro Code Complete, é o fenômeno cultural observado em tribos indígenas/aborígenes, durante a segunda guerra mundial, que envolviam impactos entre duas civilizações, sendo uma moderna em aspectos tecnológicos e outra primitiva. Durante a guerra, soldados americanos necessitavam pousar em ilhas desertas para recarregar combustíveis ou armar mísseis, entretanto muitas dessas ilhas visitadas eram habitadas por esses povos. Ao ocorrer o choque das civilizações, os primitivos imaginavam que os soldados, com todo seu aparato, fossem deuses. Depois da partida da civilização moderna, os indígenas costumavam fazer rituais em determinados períodos do ano com o intuito de invocar os supostos deuses soldados, mudando assim o comportamento cultural/religioso do local.

Ao trazemos esse conceito para computação temos situações clássicas que vivemos no nosso dia a dia, talvez a mais popular seja : Ao perguntar a um desenvolvedor/gerente/engenheiro: – Para que serve esse pedaço de código? Ele te responde: – Não sei, mas não mexe aí! Pode parar de funcionar! Em outras palavras o desenvolvedor possui um tipo de ritual para realizar determinadas tarefas, como inserir código legado, bibliotecas, classes que não necessariamente são úteis para a implementação do mesmo, acarretando a incompreensão sobre o sistema de forma geral.

Para falar de eXtreme go horse temos que esquecer de qualquer boa prática, Scrum, Kanbam, Pair Programming ou qualquer coisa que lembre engenharia de software, isto é, se focar em escrever código e vencer o prazo. Infelizmente é uma realidade triste do mercado, que muitas vezes pode indicar falta de comprometimento do time e falta de alinhamento de interesses entre equipe/empresa ou má gestão do líder.

A verdade é que o caminho para esses cenários(caóticos) são convergentes podendo ser resumidos em falta de maturidade da parte do líder ou desenvolvedor, insegurança, pressão, contratos com prazos irreais, falta de comprometimento da equipe, etc. Muitas vezes esses motivos também podem acarretar um efeito dominó, piorando a situação exponencialmente.

Claro, podemos determinar inúmeras hipóteses para a solução do problema de desenvolvimento de software, entretanto, é fato que a solução está bem longe de determinar metologias rígidas ou mudar conceitos das mesmas. Temos que ir além, precisamos mudar conceitos, quebrar paradigmas, criar um time com determinação e com aptidão, mensurar e explorar potenciais, trabalhar com dificuldades, amadurecer a equipe e acima de tudo cair na real.

Gestão de Projetos: mais do que metodologias

Hoje em dia ainda vejo empresas tratando o gerenciamento de projetos como algo engessado, como algo tradicional e com restrições.

  • Se você não utilizar tal metodologia não vai dar certo.
  • Se você não for certificado não vai conseguir.
  • Se você não seguir o que os especialistas falam não vai conseguir.

Que visão é essa?

Gerir projetos é muto mais do que metodologia.

Atualmente gerencio projetos em uma empresa da área de TI, onde aplico o que funciona!

Aplico o que minha equipe necessita, o que meu cliente precisa para ter os melhores resultados.

Utilizo práticas que combinam com o resultado que quero alcançar.

Gerenciar projetos é muito mais do que delegar tarefas para a equipe, gerenciar projetos é malabarismo constante de avaliação de prioridades, avaliação de recursos, prazos, riscos, resolução de problemas, entre tantas coisas que fazemos.

E quando temos a necessidade de gerenciar vários projetos ao mesmo tempo, e manter tudo alinhado, fica muito clara a necessidade da colaboração e da comunicação, alinhar equipe e interessados no projeto em busca do melhor resultado.

Gerentes de projeto não são independentes, nem fazem milagres, são totalmente dependentes do feedback das suas equipes e dos clientes. A comunicação tem papel chave nas tomadas de decisões, na identificação de riscos, na aprovação de solicitações.

Use modelos, mas não esqueça que de nada adianta a melhor metodologia se não tem profissionais comprometidos com o que fazem. Metodologias não salvam projetos. Projetos são etapas que possuem inicio e fim, e precisam de profissionais envolvidos com o que fazem.

De nada adianta ter um gerente de projetos certificado em várias tecnologias, se o mesmo não consegue se comunicar com eficaz com seu time de desenvolvimento. De nada adianta ter conhecimento das melhores práticas, se na hora de por a “mão na massa” não sabe qual a melhor decisão tomar.

Antes de entrar nessa linha de gestão de projetos, só enxergava pessoas com o perfil “gerentão”, sim, aquele que pensa que manda em todo mundo e que não faz nada para o bem do seu time e da organização. Depois que tive contato com essa área, conheci várias pessoas que estão envolvidas e conseguem fazer um ótimo trabalho deixando de lado aquela velha visão de um gerente de projetos que não faz nem a metade do que promete, e que sequer se importa de verdade com as pessoas envolvidas nos projetos que gerencia.

E essa experiência firma mais minha visão, de que boas metodologias não vão te salvar, se você não souber articular, perceber as atitudes, as emoções das pessoas envolvidas, se você não sentir na pele o que sua equipe está sentindo, não vai conseguir bons resultados.

Pessoas são a chave para o sucesso. Esqueça o gerentão, e direcione o foco na sua equipe, na boa comunicação com os envolvidos, na colaboração entre as funções. Nos resultados que podem ser alcançados se você conseguir liderar de forma saudável, sem prepotência, sem arrogância, apenas sendo um líder. Onde as pessoas acreditam no que você faz, e fazem junto com você, e o melhor de tudo, gostam do que fazem.

Me arrisco a falar que se você conseguir perceber as limitações da sua equipe, perceber as necessidades, se comunicar de forma clara, e dar autonomia para o time na medida que o mesmo for adquirindo maturidade, as coisas vão dar certo.

Nessa área, onde os riscos são gigantes e as pessoas são imprevisíveis, o melhor a fazer é manter a sinergia do time, alinhar os objetivos e por a mão na massa, de verdade.

Você pode me xingar no Twitter!

Teste está morto parte 2

Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.

A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.

Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.

Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.

Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.

O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.

Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.

Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.

Um produto errado é muito pior do que um produto com o comportamento errado.

A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.

E como podemos testar a idéia?

A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)

Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes tradicionais.

Sinais do Testpocalypse:

– Diminuição no numero de contratações
– Comoditização dos testadores
– Saída dos antigos líderes e ausência de novos
– Mais e mais empresas partindo para o Post-Agile

Acompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)

Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.

P.S. Todas as imagens utilizadas estão nos slides da apresentação, disponível aqui.

Teste está morto parte 1

Não restam dúvidas de que automação de testes é uma atividade fundamental no desenvolvimento de sistemas. Desde os testes unitários até os de aceitação precisamos cada vez mais de uma estrutura que permita a entrega de aplicações de maior qualidade num menor espaço de tempo.

Na internet existem diversos materiais e vídeos, que podem nos ajudar a progredir nesse caminho. A indicação de hoje são os vídeos do Google Testing Automation Conference, conferência do google, que reúne os mais respeitados profissionais. Na página da conferência você encontra os vídeos e os slides das palestras realizadas. Buscando um pouco mais você pode encontrar também os vídeos das edições anteriores.

GTAC 2011 - Logo

A palestra de abertura da edição de 2011, apresentada por Alberto Savoia, têm como título Test is Dead (Teste está morto), ficou curioso? De forma brilhante, o mesmo passeia pelas metodologias de desenvolvimento de software, finalizando com os motivos que o levam a crer que o teste está morto.

São 35 minutos de palestra, somados a 15 minutos de perguntas. Logo, caso não possa parar agora, guarde o link e assista numa melhor oportunidade, vale bastante a pena.

Quer saber mais sobre como o pessoal testa as aplicações no google? Acesse o blog mantido por eles.

Outros vídeos interessantes do pessoal do google podem ser encontrados na página do youtube – Google Tech Talks.

Na próxima semana, publico a parte dois do post, onde comentarei sobre alguns dos pontos discutidos na palestra acima.

Imagine um mundo SEM bugs no software

Na indústria de software estamos habituados a ideia de que todo software possui defeitos e que pouco podemos fazer para mudar isso. No vídeo a seguir, de apenas 9 minutos, Jeff McKenna, co-fundador do Scrum apresenta uma visão radical: um mundo sem bugs no software. O vídeo foi extraído de seu próximo livro “Conscious Software Development.”

O vídeo é excelente e nos faz pensar principalmente na atitude em relação aos bugs que temos em nossos projetos. Segundo Jeff, não basta corrigirmos os defeitos encontrados precisamos entendê-los e aprender com eles, só assim construiremos sistemas SEM defeitos.

Assista ao vídeo. Em seguida, destaco os principais pontos abordados por McKenna.

 

Temos sistemas de gerenciamento de defeitos, realizamos triagens, mas será que em algum momento pensamos sobre o que eles são? ou como surgiram? como fazer para não surgirem mais?”

Segundo Jeff, temos sido muito complacentes com os defeitos, acreditamos que existem muitos, e que os mesmo são parte de todos os sistemas. Porém, o autor não acredita nisso e nos convida a imaginar um mundo SEM bugs de software.

“Podemos atingir números bem menores do que as pessoas consideram razoável, e isso pode ser feito de maneira simples”

McKenna indica que, a simples conscientização a respeito dos bugs já possibilita imensos ganhos. Precisamos entender porquê eles estão presentes e agir para evitar novas falhas.

Como diminuir a quantidade de bugs?

– Reduzir o tempo entre a introdução de um bug e sua correção

A medida leva em conta o momento no qual o bug foi introduzido no sistema e não o momento em que o mesmo foi detectado. Para isso é necessário utilizar as ferramentas de controle de código, assim, após identificado o motivo do defeito podermos voltar versões do código e identificar o momento em que ele ocorreu.

Olhando para o exato momento em que o erro aconteceu podemos aprender a escrever menos bugs. Porque esse é o verdadeiro objetivo.”

O objetivo não é encontrar mais bugs e a função dos analistas de qualidade não se resume a isso.

“Classificação e triagem de feitos são uma perda de tempo, em termos de aprendizado sobre como escrever menos bugs”

Segundo McKenna, pouco importa a severidade do defeito e suas características, pois geralmente o critério de correção está diretamente ligado a questões de negócio, como a importância de um determinado cliente. Logo, se estamos tentando aprender a escrever menos bugs, não há diferença entre os mesmos, sejam eles de alta ou baixa prioridade todos são comportamentos não esperados do sistema.

“Corrigir os defeitos era a atividade de maior prioridade”

Jeff, exemplificou suas recomendações com as seguintes práticas executada em um de seus projetos:

1- Sempre que um bug surgisse, a primeira pessoa que estivesse livre passaria a trabalhar no defeito. Onde, um profissional era considerado livre quando terminava a tarefa que estava executando no momento. Bugs possuem prioridade mais alta, que todas as demais tarefas ainda não realizadas. Desse modo, no máximo em alguns dias o defeito era analisado.

2 – Corrigir e entender o problema. A mais alta prioridade era a correção do defeito, associado a criação de novos testes automáticos. Porém, o mais importante é você falar porquê aquele bug estava lá, a razão do mesmo ter ocorrido.

“O que queremos fazer é encontrar o bug o quanto antes para que possamos consertá-lo o mais cedo possível e provar o aprendizado”

Para McKenna, temos o prazo máximo de até 6 meses da introdução de um defeito, para podermos aprender algo através de sua correção, após isso a oportunidade de aprendizado terá sido desperdiçada.

“O objetivo real é escrever software SEM defeitos.”

E para atingir esse objetivo, a principal característica que temos que desenvolver é a de olhar sempre para frente. Se ficamos sempre olhando para trás 6 meses, 1 ano, analisando um código que não vemos a muito tempo, isso literalmente é perda de tempo. Então, o que queremos fazer é olhar para frente a todo o momento e ter a atitude de ZERO defeitos.

“Um bug é algo que você esmaga imediatamente.”

Ao eliminar rapidamente os bugs encontrados acabaremos com tarefas, como a priorização de defeitos. Afinal, a quantidade de bugs pendentes será sempre pequena e desse modo o foco poderá ser maior no que está sendo construído.

Este é um vídeo para ser visto diversas vezes, e se conseguirmos absorver sua ideia central, penso que, poderemos melhorar ainda mais nossos processos e principalmente nossa atitude.

Conheci esse vídeo primeiramente no Software Testing Club, uma excelente fonte de informações para testadores, com bons textos e vídeos sobre a área. Espero que tenham gostado.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.