Saga do programador

Nessa parte, abordarei as palestras e os lightnings talks que assisti no Agile Brazil 2011. A leitura deste post ficaria muito densa se eu colocasse tudo o que vi no evento. Sendo assim, a ideia é fazer uma espécie de “show do intervalo” apresentando os “melhores momentos” do evento.

Continuous Inspection – An effective approch towards Software Quality Product Improvement

Como saber como anda a “saúde” de nosso código? Usei o termo “saúde” de propósito, pois foi a mesma analogia que Gabriel Moreira e Roberto Pepato usaram. Em um CTI, por exemplo, cada paciente possui um aparelho ligado ao seu corpo que fica o tempo inteiro monitorando suas funções vitais, tais como: pressão arterial, batimentos cardíacos, etc. Se o valor de qualquer um desses parâmetros entrarem em uma faixa não desejada, o monitor irá alertar. Será que existe alguma forma de usar esta abordagem para monitorarmos a qualidade do nosso código? Sim, existe. Existem diversas ferramentas capazes de fazer isso. Continous Inspection é o nome desta técnica. Entretanto, o importante aqui não são as ferramentas e nem os nomes. É interessante saber qual a motivação para tudo isso. Primeiramente é receber um feedback de nosso código o quanto antes. Reparem como os mesmos valores ágeis aparecem o tempo todo! Porém, neste caso o principal objetivo é conter o débito técnico.

Segundo os palestrantes, o débito técnico é como o predador do filme, ou seja, mesmo sendo difícil de ser visualizado, está sempre ali pronto para fazer um estrago. Como falei na primeira parte, o débito técnico reduz a capacidade do software de responder às mudanças diminuindo, assim, a agilidade da empresa. Outro ponto que vale a pena ressaltar é que o débito técnico pode chegar em um nível tão crítico que pode fazer com que o time precise passar muito mais tempo corrigindo defeitos e ajustando a arquitetura, do que efetivamente desenvolvendo novas funcionalidades, que é o que nós desenvolvedores gostamos de fazer, não é verdade? Isso acaba criando um círculo vicioso, pois começam a surgir “casas de marimbondo” pelo código que ninguém tem coragem de mexer. Eu recomendo todo desenvolvedor a ler um estudo realizado em 2002 pelo NIST chamado “The Economic Impacts of Inadequate Infrastructure for Software Testing”. Tem uma série de dados interessantes neste estudo. Destaco dois em especial: a) Bugs custaram à economia americana 60 bilhões (é bilhão mesmo e não milhão) de dólares e b) Em muitas organizações os desenvolvedores passam mais de 80% do tempo corrigindo defeitos.

Mas agora é que vem o problema. Manter o código manutenível e escalável é um desafio muito grande. Para agravar ainda mais, metodologias ágeis pregam pelo pragmatismo e desencoraja o foco na arquitetura. A grande questão aqui é não ser radical. A ideia é controlar o débito técnico e não eliminá-lo por completo. Controlar o débito técnico significa não apenas mantê-lo baixo, mas sim ser capaz de rastreá-lo também. Em muitos momentos no desevolvimento de um software, inevitavelmente, você terá que abrir mão do capricho no código em função do pragmatismo. Isto é perfeitamente aceitável. O problema é que quando não há um mecanismo de monitoramento, você acaba perdendo a rastreabilidade dos pontos que precisam ser melhorados no seu código. Além disso, conforme mostrado na palestra, muitas ferramentas de Continous Inspection podêm ajudá-lo a priorizar o seu trabalho identificado problemas no código das partes mais críticas do sistema. Por exemplo, refatorar uma classe que é alterada com maior frequência tem maior prioridade do que outra classe que é pouco alterada.

Esta foi a palestra mais útil para mim, pois tem tudo a ver com os problemas que enfrento hoje. Todas as imagens acima foram retiradas da apresentação dos palestrantes. Vale a pena conferir.

A sociedade do Dojo e os grupos de capoeira.

Confesso que não fazia a menor ideia de estava por vir nessa palestra. Entretanto, como sou entusiasta dessas analogias desconexas, acabei arriscando. E valeu o risco. Bruno Pedroso trouxe à tona um problema que é realidade em nossa comunidade: a dificuldade de organizar Coding Dojos. O problema parece o mesmo em todas as regiões do Brasil. Todo mundo gosta e está convencido que vale a pena, mas ninguém aparece nos dojo’s. Conforme Bruno mostrou, os grupos de capoeira passaram por esse mesmo problema no passado. Para resolvê-lo, foi criado o sistema de cordel que tem a ver com o reconhecimento que um capoeirista tem dentro do seu grupo. Bruno apresentou uma iniciativa do pessoal de Brasília que seria algo como um ambiente de pontuação inspirado (mas diferente) do sistema do stackoverflow. O bacana dessa palestra é que o autor trouxe não apenas um problema, mas sim uma proposta inicial de solução. Além disso, a parte final da apresentação virou quase uma mesa redonda onde muitos participantes mostraram ideias interessantes. Chegaram a propor incentivos financeiros. Eu sou um pouco contra esta ideia, pois as pessoas podem esquecer da real motivação dos dojo´s. Vou deixar registrado aqui uma ideia que me ocorreu durante a escrita deste post. Poderia-se pensar em uma espécie de incentivo por parte das empresas. Em vez de apoio financeiro, as empresas poderiam apoiar com horas de trabalho e/ou oferecendo o espaço/estrutura para realização dos dojos. Na minha opinião, o custo disto é bem inferior ao de um treinamento tradicional e a eficiência pode ser maior também. Creio que uma abordagem como esta, iria otimizar a capacitação do time a médio/longo prazo. Nessa história todos saem ganhando.

Como formar um programador 10x

Esta é o tipo de palestra que é impossível expressar com palavras o quão boa foi. Luca Bastos, sem papas na língua e com um vocabulário jovem, cativou toda a audiência. A sala ficou literalmente pequena para Luca. Muitas pessoas assistiram em pé, pois não havia cadeiras suficiente para todos. Luca apresentou ideias já conhecidas para aumentar o nível de conhecimento de programadores iniciantes. Ele discutiu, com muito bom humor, técnicas como pair programming, revisão de código e etc. Um dos momentos mais interessantes foi quando ele mostrou um slide com uma foto dele praticando pair programming com uma desenvolvedor que tinha um terço da idade dele. É uma pena que não lembrei na hora de fotografar esse slide para compartilhar aqui com vocês. O carisma do Luca é impressionante. Um fato curioso: durante a palestra eu postei no Twitter pedindo um keynote para o Luca Bastos no próximo Agile Brazil e em poucos segundos foi “retuitado” por dezenas de pessoas. A apresentação foi recheada de tiradas engraçadas, foi deixar algumas aqui:

• “Planning poker? Eu chuto tudo!”
• “Pair programming funciona, porque o desenvolvedor tem vergonha de fazer bacalhau ao lado do colega.”
• “Programar é do c@#$. Quando o teste passa você é f@#$, quando o teste falha você é um m@#$%.”
• “Sou contra pair programming 100% do tempo, porque o desenvolvedor precisa ter um momento de intimidade com seu código”.

Ciclos de Avaliação de Pressupostos: Entendendo Lean, Kanban e Agilidade sob uma nova perspectiva

Nesta palestra, Alisson Vale apresentou sua ideia sobre avaliação de pressupostos. A ideais de Alisson soam para mim como uma camada mais alta de abstração do conceito de feedback. Outro ponto que ele destaca é que avaliação de pressupostos é uma oportunidade de aprendizado e uma forma de avançar em um cenário repleto de incertezas. No entanto, existe uma variável importante neste sistema que não pode ser ignorada: o tempo. A proposta de Alisson é minimizar o tempo entre a criação de um pressuposto e sua avaliação. Para representar esse conceito foi proposta a seguinte expressão:

? – min(t) => !

onde, ? representa a criação de um pressuposto, ! representa a avaliação de um pressuposto e min(t) representa o objetivo em diminuir esse tempo.

Isso parece muito familiar, não ? Quem pensou em TDD acertou em cheio. O que torna o TDD tão poderoso é exatamente essa capacidade em minimizar o tempo em que um pressuposto surge e o tempo no qual ele foi avaliado. E o interessante é que isso ocorre em diversos aspectos do TDD. O primeira deles é o próprio resultado do teste. Quando um teste falha significa que sua nova especificação não está sendo atendida pelo código. Neste ponto, você acabou de minimizar o tempo t. O segundo aspecto que merece destaque é o tempo de identificação de uma regressão. Executar todos os testes após alterarmos nosso código é equivalente a validar o seguinte pressuposto: “Minha alteração regrediu o sistema?”. Reparem como estamos minimizando o t (em geral os test runners executam centenas de testes de unidade em um único minuto). Um terceiro, e não menos importante, aspecto é o constante feedback que o teste te dá a respeito da saúde do seu código, os tão comentados “code smells”. Interessante como o ato de escrever um único teste permite a avaliação de diversos pressupostos em um tempo mínimo! Para ilustrar o conceito, Alisson usou outros exemplos. Um deles foi relativo a avaliação de pressupostos durante a entrega de um produto. O gráfico abaixo mostra que quanto maior a frequência de releases, menor será o tempo de avaliação de alguns pressupostos tal como o feedback do cliente em relação a uma nova feature:

Esse gráfico reforça a ideia de que Continous Delivery (entrega contínua) é o caminho a ser perseguido.

Lightning Talks

Conforme já falei, esta foi a novidade que mais apreciei nesta edição do Agile Brazil. Vou destacar alguns aqui e tentar escrever em poucas linhas o que achei:

TDD – Está na hora de aplicar no seu trabalho!

Daniel Wildt trouxe à tona uma dificuldade que acredito ser muito comum no desenvolvimento de software em nosso país: convencer outros desenvolvedores dos reais valores do TDD. Pelo incrível que apareça, ainda existe muito desenvolvedor que acredita que o objetivo do TDD é testar. A palestra não foi para apresentar nenhum processo ou ferramenta para disseminar o TDD, foi apenas uma injeção de motivação para não desistirmos da ideia.

Conhecendo Domain Driven Design

A tarefa de condensar um assunto sem perda de informações importantes é algo extremamente difícil (pelo menos para mim). Falando de DDD, pior ainda. É assunto denso e extenso, cheio de detalhes. Felipe Rodrigues conseguiu uma façanha: falar de DDD, de maneira consistente, em 10 minutos. Não foi útil para mim, mas para quem não conhece nada sobre o assunto, o talk parece ter sido excelente.

Ramones ou Jazz? Ou os dois? Buscando produtividade com músicas.

Embarcados na filosofia do Pomodoro, Daniel Wildt e Hélio Medeiros apresentaram o SongDoro. Uma proposta para maximizar a produtividade com músicas que estimulem o desenvolvedor usando os mesmos conceitos básicos da técnica Pomodoro. O bacana é que eles apresentaram a possibilidade de um ambiente colaborativo onde é possível obter recomendações (ou recomendar) de músicas por outros desenvolvedores.

Domain Game: Disseminando conhecimento através de diversão.

Rafael Camargo apresentou um jogo interessante para aumentar o conhecimento do time em relação ao domínio do software que estão desenvolvendo. O Domain Game é um jogo onde os membros do time deverão responder perguntas, geralmente feitas pelo PO, sobre questões do domínio. Se ele acertar, ganha algum “brinde” (Rafael usou bombons como exemplo). Caso erre, o membro do time deve “pagar” o PO com um bombom. Então, quem fica com mais bombons ao final do jogo é o vencedor? Não! O objetivo do jogo não é descobrir quem sabe mais sobre o domínio, mas sim nivelar o conhecimento de todo o time de forma divertida. Então se não há disputa não é jogo? Alguém aqui já venceu ou perdeu num jogo de frescoball ?

UI-TDD : Quem disse que não é possível?

Bruno Pedroso (o mesmo da palestra da capoeira) fez algo que parecia impossível: um LT prático. Ele extraiu alguns pontos do TDD que são aplicáveis no desenvolvimento de interfaces web. Usando um editor de textos, ele escreveu a especificação de um gráfico de radar como se fosse um teste unitário assumindo inicialmente que o teste estava quebrado. Em seguida, escreveu um código inicial em JS e o teste passou. Daí em diante, ele fez os passos comuns do desenvolvimento orientado a testes, evoluiu a especificação, refatorou o código até chegar ao ponto em que julgou que a especificação foi atendida. Dessa forma, Bruno conseguiu quebrar o mito de que não tem como aplicar TDD quanto estamos colocando funcionalidade na interface gráfica. É claro que não há o benefício da automação, mas pelo menos é possível criar um código com maior qualidade com essa abordagem.

That´s it. Aguardem o terceiro e último post sobre este feedback!

Tags: AGILE BRAZIL, Kaban, METODOS ÁGEIS, SCRUM, tdd

This entry was posted on Friday, July 8th, 2011 at 12:15 and is filed under Continuous Delivery, Continuous Inspection, Java, Kaban, Metodologia, OO, SCRUM, tdd. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.