Red, Green… Pause!

26.novembro.2008
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á 😉

Anúncios

One more achieved goal

24.novembro.2008

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

Certified ScrumMaster

Sun Java Certified Programmer

Que venha 2009. 😉


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

21.novembro.2008

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

20.novembro.2008

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


Um ambiente agradável

19.novembro.2008
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

18.novembro.2008
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:


Usando Test-driven Development – Semana 1

17.novembro.2008
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.

😉