Red, Green… Pause!

Essa semana e em parte da próxima, estarei dando treinamento na empresa e, infelizmente, não vou conseguir publicar alguma coisa com conteúdo mais detalhado.

Estou devendo:

• Minha segunda semana usando TDD, mais alguns erros e mais alguns acertos
• Fazendo manutenção de código legado e um caso prático num dos projetos em que trabalhei
• Aprendendo Ruby. Resolvi meter as caras na linguagem da moda e vou dizer quais foram minhas impressões iniciais

Até lá

One more achieved goal

Na metade do ano estabeleci como meta conseguir duas certificações.
Hoje consegui a segunda.

Que venha 2009.

Declínio e queda das metodologias ágeis – Ecos do além

O debate continua ecoando. Na última pesquisa, o Google acusou 9.800 páginas sobre o assunto [1].

Um dia esse site chega lá =)

Para quem teve ou não feriado

Crianças, enquanto estiverem programando, não se esqueçam: A gambiarra é um bumerangue.

Um ambiente agradável

Estava pensando no que faz um ambiente de trabalho um lugar agradável. Com certeza você vai discordar de alguns pontos, mas sinta-se livre para adicionar ou contestar pelos comentários.

• Liderança, não chefia.
  Isso aqui vai dar assunto para um post inteiro. No sentido utilizado aqui, um líder auxilia, gera motivação e comprometimento. Um chefe dá ordens e trabalha pelo modo de comando-controle.
• Horários flexíveis
  Polêmico, mas eu acho importante. Existem pessoas que preferem entrar as 8 e sair as 17. Seja para chegar logo em casa, seja para fugir do trânsito. Outras preferem entrar as 9 e sair as 18, ou então chegar mais tarde por ter ficado até tarde no dia anterior. Tudo é questão de conversar e entrar num acordo que seja bom para ambas as partes, usando sempre de bom senso. A abordagem de se utilizar um ‘cartão de ponto’ na entrada do escritório, é algo antiquado e que não traz benefício algum, seja à empresa, seja ao funcionário.
• Controle por prazos e qualidade, e não por presença física
  Um ponto que dificilmente encontro. A partir do momento que é dada uma tarefa, é definido o que deve ser feito, e o prazo, não vejo motivo para você ficar amarrado ao pé da mesa. Claro, desde que você mantenha a visibilidade do que está sendo feito. Muitos chefes acreditam que um funcionário mantido sob vigilância produz mais. É discutível. Já vi muito projeto dando errado com funcionários cumprindo horário religiosamente e chefes munidos de chicotes e projetos dando certo com lideranças flexíveis e comprometimento de todos os envolvidos.
• Liberdade técnica
  Um exemplo de como não fazer: você trabalha numa fábrica de software, recebe o diagrama de classes pronto e sua função é rechear os métodos com código que funcione. Refactoring? Nem pensar, isso é retrabalho. E além do mais, quem você pensa que é para questionar o trabalho sagrado do analista/arquiteto/wtv?
  Outro ponto, e esse eu vejo muito em quase todo lugar, é a imagem de que  desenvolver testes automatizados tornam o desenvolvimento mais lento e improdutivo. A minha tarefa, como desenvolvedor, é entregar código funcionando, com qualidade, fazendo o que o cliente precisa, dentro do prazo previsto. Como eu vou fazer isso é problema meu. Esse é o ponto.
• Ambiente tranqüilo e silencioso
  Me chamem de chato, mas eu não consigo trabalhar com alguém brigando com o namorado pelo telefone, gerente comentando as últimas aventuras sexuais em voz alta ou alguém ouvindo som alto (mesmo que  seja algo que eu goste) num momento em que precise de concentração. Um espaço separado é uma boa idéia, como por exemplo, uma sala de reuniões, ou o uso de fones de ouvido, se for o caso.
  Conversar é proibido? Pelo contrário, é algo importante e necessário, mas novamente, doses de bom senso nunca fazem mal.
• Temperatura agradável
  Ambiente fechado, abafado e quente é insuportável. Escuro e com ar congelante também não é nada agradável. É difícil encontrar um consenso quando vinte pessoas trabalham juntas, mas fugir dos extremos já é uma boa coisa.
• Equipe com bom nível técnico
  Por experiência própria, trabalhar com pessoas de nível técnico maior que o seu faz com que você se desenvolva mais rapidamente. Com pessoas com mais ou menos o mesmo nível técnico faz com que a equipe cresça junta, mais lentamente, ou simplesmente fique estagnada, dependendo da motivação de cada um.
• Ter uma equipe
  Quatro pessoas juntas não formam uma equipe, assim como dois monólogos não formam um diálogo.
• Café
  Café a vontade e sem miséria, afinal, somos desenvolvedores, não?

Como tem se tornado comum, ao publicar o post eu acabo lembrando de alguma coisa para acrescentar, portanto não estranhe se a lista parecer incompleta.

Declínio e queda das metodologias ágeis

James Shore escreveu um artigo [1] que causou uma série de discussões como há muito tempo eu não via. Antes de continuar aqui, leiam. Eu espero.

Muita coisa absurda é feita em nome do Scrum ou de Agile, assim como muitas atrocidades já foram cometidas em nome do RUP, do PMBok ou da metologia que vier à sua cabeça. O problema é que, enquanto as anteriores ficaram com a fama de burocráticas e lentas, as metodologias ágeis em geral carregam a idéia errônea de serem desorganizadas, bagunceiras e irresponsáveis. Ao mesmo tempo, já ouvi casos onde o nome ‘Scrum’ foi associado a projetos sem definição de pronto, processos amarrados e burocráticos ou mesmo anarquia (no sentido mais comum do termo).

Aí você pergunta: ‘Ué, processos amarrados e burocráticos? Mas não era pra ser ágil?‘. Sim, era. O Scrum, em sua definição formal, não é uma metodologia, mas um framework, um conjunto de práticas e idéias que levam, antes de mais nada, a mudanças culturais e comportamentais. Essas sim é que vão causar melhora na comunicação, aumento de produtividade e toda essa coisa que tentam vender como um produto na caixinha.

Há duas semanas ouvi um profissional de TI (ex-IBM e apaixonado por RUP, segundo o próprio), dizendo que Scrum não presta porque não tem um livrão de 800 páginas explicando passo a passo como fazer. ‘Vira zona’, nas palavras do colega.

Também há algumas semanas, um conhecido evangelizador da Microsoft publicou suas impressões sobre Scrum [2]). O cidadão tem a infelicidade de dizer que “Scrum é fácil de usar”. Claro, é sempre muito fácil mudar antigos hábitos, perder vícios e mudar a cultura da empresa inteira. É sempre muito fácil ter o comprometimento de todos os membros da equipe, ter facilidade de comunicação e mesmo criar o conceito de equipe dentro da empresa.

Assim como aconteceu nesse caso, pessoas tidas como especialistas começam a vender Scrum, ou qualquer metodologia ágil como se fosse algo fácil e rápido de aplicar. Projetos inteiros vão para o vinagre por completa falta de organização e, principalmente, por falta de um entendimento verdadeiro do que realmente é ser ágil.

Agile não é só Scrum, não é bagunça nem falta de organização. Scrum não é Kanban e Post-it com reuniões em pé. Ser ágil não é só entregar em prazos curtos, não é só usar TDD, BDD, XP ou a PQP de sigla que você achar por aí. Não é jogar fora a documentação, nem deixar de modelar, não é trabalhar sem contrato, não é criar piscinas de bugs, não é descer a lenha em PMP ou queimar o PMBok em praça pública. Agile, Scrum, Crystal, XP, etc são, antes de mais nada, bom senso.

Nem mais, nem menos.

Referência:

• Manifesto Ágil – http://agilemanifesto.org/

Usando Test-driven Development – Semana 1

Hoje completei uma semana utilizando TDD (Desenvolvimento orientado a testes) em tempo integral. Quando eu digo ‘tempo integral’, entenda como ‘usando do jeito certo’, criando testes primeiro para depois programar a funcionalidade.Com a ajuda de Kent Beck (Test-Driven Development by Example), e dando várias e boas cabeçadas, consegui juntar uma listinha de itens para ajudar os próximos corajosos que resolverem se aventurar nesse modo de desenvolver software.

• Crie uma história
  Esse é o início de tudo. Provavelmente a história já existe e chega na forma de um requisito. Você pode definir o formato que ela vai ter, ou o projeto já deve ter algum padrão. Nesse projeto eu uso a seguinte estrutura:
  Quando fulano faz tal ação, acontece tal resultado.
  Se você está programando um software de PDV, por exemplo, ela pode ser traduzida como ‘Quando o operador de caixa ler o código de barras, eu devo exibir o nome do produto e o preço‘.
  Nada de extraordinário ou de complicado. Quem já XP alguma vez na vida deve conhecer por User Story.
• Simplifique
  Provavelmente você não vai conseguir resolver com meia dúzia de linhas de código. Então comece com algo simples, sem perder o foco e sem esquecer do problema que você tem para resolver.
  Usando o exemplo acima, nós logo notamos que o código de barras vem de algum lugar, que as informações sobre o produto estão em outro lugar, e que alguém vai utilizar o resultado disso.
  Com isso, o problema maior se torna três problemas menores e mais simples de resolver.
• Mantenha uma lista de itens a fazer
  Essa veio direto do livro do Beck, e que eu apanhei por não ter feito. Crie uma listinha, num pedaço de papel mesmo, com os itens que forem aparecendo, as dúvidas que você tiver e os testes que você pretende implementar para aquele problema menor que você resolveu atacar.
  Lembre-se de manter a simplicidade e escrever numa linguagem que você possa lembrar no dia seguinte. No meu caso, tive um fim de semana no meio do desenvolvimento.
• Um teste por vez
  Outro erro que cometi: criar vários testes de uma vez.
  De repente eu tinha três testes em vermelho, e só podia resolver um por vez. Isso aumenta o nível de stress e dificulta a visualização do problema.
  Nesse caso específico eu tinha um objeto sendo manipulado no método testado, e ao dar return, eu criava uma instância nova e limpa ao invés de devolver aquela que já estava tratada.
  Mais ou menos isso:

  MeuObjeto fazAlgumaCoisa(Valor parametro){
MeuObjeto retorno = new MeuObjeto();
retorno.qualquerCoisa(parametro);
return new MeuObjeto();
}

  Triste…

• Um passo por vez
  Criar um teste por vez nos leva a dar pequenos passos, um de cada vez, conforme seu código vai evoluindo. Claro que um pequeno passo para um Martin Fowler pode ser uma maratona para mim.
• Não se preocupe com desempenho
  Pelo menos num primeiro momento. Otimização sem critérios pode ser uma excelente fonte de bugs aparentemente sem sentido.
• Seja realista
  Pode apostar: se você nunca usou TDD, você vai perder mais tempo e ficar menos produtivo no início. Todo aprendizado é assim, e com TDD não seria diferente. Então, use o bom senso, se você tem uma tarefa para entregar amanhã cedo, não invente. Não tente usar TDD pela primeira vez na vida em um projeto atrasado e com cronograma estourado. No final das contas você vai ficar com fama de irresponsável, de improdutivo e o TDD vai levar a culpa pelo fracasso do projeto.
  Após o quarto dia eu comecei a sentir a diferença. O código passou a fluir mais rápido, e eu estava confiante de poder prosseguir sem medo de estar ferrando com o resto da aplicação.
  Claro que o fato de você estar criando testes torna o seu código muito mais confiável e menos sujeito a erros, mas eu não recomendo que você considere-o 100% correto e livre de bugs, pelo menos no início. Auto-crítica costuma ser uma virtude nesse caso.
• E, de novo, simplifique.
  Como dizia um professor que tive, ‘não invente, faça o básico‘. O importante, num primeiro momento, é entregar software funcional. O teste serve, antes de mais nada, para verificar que seu código recebe uma entrada e devolve a saída prevista. Não perca tempo reinventando a roda e tentando parecer sagaz aos olhos de outros programadores. Pensar simples, ao contrário do que parece, é uma das coisas mais difíceis de se aprender.

Essas são as minhas impressões. Nada impede de escrever sobre a segunda semana e dizer algo oposto ao que está em algum ponto daqui. O aprendizado consiste em aprender coisas novas e corrigir falhas antigas.

Pensamento solto

É algo que eu tenho como um mantra: Sempre que o código começar a ficar complicado demais, levante, vá tomar uma água, respire, lave o rosto se necessário. É bem possível que você esteja indo pelo caminho errado.

Livros técnicos em português

Ontem, na hora do almoço, estava discutindo com um colega de trabalho a respeito de se ler livros técnicos em inglês ou português.

Ele é da opinião de que é melhor ler livros em português, já que é nosso idioma nativo, normalmente são mais baratos e não há mal algum em uma ou outra tradução errada. Nas palavras dele, geralmente é possível entender o que o autor quis dizer no idioma original. Outro ponto comentado é que, na maioria dos casos, o livro importado demora mais para chegar, já que costumamos comprá-los pela Internet.

Há uns anos, eu não pensaria duas vezes ao comprar um livro traduzido, adicionando um motivo aos citados acima: eu ficava totalmente desconfortável com algo que não estivesse em português.

Um dos livros que comprei nessa época foi sobre UML, da péssima conceituada Editora Ciência Moderna. No capítulo sobre Diagramas de Classes – muito fraco, diga-se de passagem – havia várias referências ao uso de portas. Na terceira leitura é que eu fui entender que aquilo era a tradução porca para interfaces, um conceito usado em orientação a objetos. Não satisfeito com o erro, comprei um de certificação para Java 1.4 da mesma editora. Se tivesse dependido apenas dele para passar na prova, estaria perdido.

Particularmente, prefiro livros no original em inglês por uma série de fatores:

• Não quero ficar adivinhando o que o tradutor achou que o autor quis dizer. As vezes o livro já trata de um assunto complicado o suficiente para eu ter que ficar brincando de vidente.

• Geralmente não existe tanta urgência em ter o livro em mãos. Se houver, a Internet tem dezenas de blogs especializados, tutorias ou sites de fabricantes com exemplos. Raros os casos onde isso não se aplica.
• Geralmente sites especializados e documentação também estão em inglês.
• Eu posso treinar minha fluência no idioma. Aquela desculpa clássica de que ‘meu inglês não é muito bom’ é realmente triste. Pode apostar que o inglês do sujeito vai continuar não sendo bom por muito tempo.

Infelizmente, ainda temos muito pouca literatura de qualidade escrita por brasileiros. Boa parte do que se encontra por aí são cópias e traduções de obras estrangeiras. Ou então, temos os Ramalhos da vida, que se dizem especialistas dos assuntos mais diversos, partindo de bicicletas ou vinhos até bancos de dados relacionais.

Com certeza alguém vai discordar de algum dos pontos, mas criar uma cultura de ler e aprender em um idioma que não seja o português é um grande diferencial no desenvolvimento profissional e mesmo cultural. Recomendo.

Update as 15:51:

Leitura recomendada: http://akitaonrails.com/2007/4/14/off-topic-seja-arrogante

Um modelo diferente

Estava pensando num modelo de negócios (ach) diferente para lidar com equipes de TI, onde os desenvolvedores (analistas, programadores, testers, etc) receberiam bônus por qualidade de software.

Por exemplo:

• Quantidade de bugs comprovados (qualidade interna)

• Avaliação dos usuários (qualidade externa)

e não simplesmente por ‘linhas programadas’, nem por ‘funcionalidades criadas’, já que isso criaria uma corrida do ouro para que fosse feito o máximo de itens possível, com o máximo de linhas possível, mas com a qualidade sendo jogada para escanteio.

Outro item que seria interessante, para evitar que mais nada fosse criado pra nao gerar novos bugs, seria avaliar também o retorno de investimento estimado para os clientes. Ou seja, quanto mais o cliente ganhou com isso, maior seria o bônus. Isso obrigaria a equipe a focar só no que é importante, e fazer bem feito.

Claro que isso ainda é só um rascunho, mas já dá uma boa idéia de como isso poderia funcionar.