Retrospectiva de Sprint para o final de ano

Como todos sabem, final de ano é correria para todo mundo e acaba não sobrando tempo para muita coisa. Eu por exemplo, queria preparar um post técnico bem legal para fechar o ano bem, mas infelizmente vai ficar para o começo de 2011. Para este post, farei uma analogia entre a reunião de retrospectiva do sprint, da metodologia scrum e uma análise de como foi sua carreira profissional neste ano.

Bom, para aqueles que já conhecem ou trabalharam com o Scrum já sabem como a reunião de retrospectiva funciona, mas para os que ainda não conhecem, sugiro que leiam o resumo feito pelo pessoal da IMPROVE  IT: http://improveit.com.br/scrum, pois usarei alguns termos utilizados na metodologia.

A idéia de escrever este post, surgiu de um estalo que tive e achei bem interessante: por que não comparar nosso ano com um sprint ? E melhor ainda, por que não analisar nosso ano, ver o que houve de ruim para tentar melhorar e o que teve de bom para se aproveitar como em uma retrospectiva de sprint ?

Então, mãos à massa, post its de pontos negativos na parede e vamos lá: analisem os aspectos negativos do seu ano profissional, aquele projeto que não foi entregue no prazo(o que melhorar para mudar, o que fazer para conseguir alcançar o prazo, por que atrasou o projeto), aquele estudo que teve que ser deixado de lado, aquelas horas extras que foram apenas um favor e não remuneradas, aquele freela que você deixou passar.

Agora os post its com pontos positivos: aquela promoção que você conseguiu, aquela metodologia que você conseguiu colocar em prática e obteve bons resultados, aquela tecnologia nova que você aprendeu, aquele projeto pessoal que você concluiu, a conversa produtiva que você teve com seu chefe/equipe.

Beleza, mas pra que tudo isso ?

Ué, após preencher e colocar todos os post its nos quadros de pontos positivos e negativos, é hora de discutir cada um e analisar, com você mesmo, perca um tempo tentando entender algumas coisas e melhorando sua auto-estima para aqueles pontos positivos. Com isto, acredito que você terá uma boa leitura de como foi seu ano, poderá traçar estratégias melhores para alcançar seus objetivos para o próximo ano e por que não, traçar novas metas para 2011 ?

Espero ter contribuído em alguma coisa para você que está lendo este post. Um feliz natal e um 2011 abençoado, cheio de sucesso e realizações !

Html Reader, o experimento !

Iae galera, vou aproveitar minha insônia e escrever mais um post, desta vez sobre ruby.

A bola da vez é uma aplicação que desenvolvi esses dias(https://github.com/mauriciovoto/html_reader) que surgiu com a necessidade de minha noiva estar um pouco revoltada de pedirem em seu trabalho para fazer um exaustivo trabalho de ctrl C + ctrl V. Ela tinha que copiar informações de todos os Procon do estado de SP. Daí que me surgiu a ideia de desenvolver algo para ajuda-la.

Esta foi uma ótima oportunidade para botar em prática algumas coisas que havia e venho estudando, algumas delas, recomendo fortemente, como o jeweler, o rspec(quem acompanha o blog e meu twitter sabe que venho estudando bastante esta ferramenta), o infinity_test e outras gems como hpricot, rest-open-uri e spreadsheet. Além de ser outro laboratório de git pois tenho o péssimo costume de desenvolver aplicações e mante-las em minha máquina.

Bom, para resumir o que utilizei, o jeweler é uma ferramenta para geração de gems, ou seja, gera um projeto ruby com uma mínima estrutura para iniciar um desenvolvimento ideal.

O rspec como já citei antes no blog, é uma ferramenta para escrever testes como especificações.

O infinity_test é uma biblioteca que permite ao desenvolvedor ver em tempo real se seus testes estão passando ou não, um autotester que a cada alteração que é feita, roda os testes em background e notifica(em conjunto com outra ferramenta, como o growl para mac os).

O hpricot e o rest-open-uri são gems que permitem a leitura do html dos sites, sugiro a leitura das documentações para quem quiser estudar, apliquei apenas o básico em minha aplicação.

Por último, o spreadsheet é uma gem para manipulação de planilhas excel, apesar da pouca documentação não tem muito segredo de uso. Também utilizei em minha aplicação o básico de geração, nada diferente do que encontramos na página da gem.

Espero que possam dar uma conferida na app: html_reader críticas e sugestões são sempre bem-vindas ! E mais uma vez agradeço ao meu digníssimo camarada @raulsouzalima pois ele me indicou várias dessas gems e também agradecer ao @danielvlopes que apresentou brevemente o jeweler em uma de suas aulas que tive o prazer de assistir.

Como convencer de que é bom testar ?

Pessoal, estou estudando aqui bastante sobre BDD, TDD e algumas ferramentas para aplicar essas técnicas de uma vez por todas em minhas aplicações Rails, portanto ainda não tenho material nem conhecimento suficiente para postar sobre este assunto aqui no blog. Ao invés disso, vou escrever sobre algo que me intriga um pouco: o que meu chefe pensa à respeito disso ?

Bom, como disse, tenho estudado para aprimorar técnicas de desenvolvimento e em um breve futuro entregar aplicações com muito mais qualidade. Isso é uma coisa que me empolga, me motiva muito à ponto de eu conversar com meu atual chefe sobre o uso em um sistema que migraremos de uma linguagem de 3 letras(que não é PHP) para Ruby on Rails e aparentemente ele não se empolga tanto. Sua motivação aparece quando falo de melhorias na estrutura, performance e usabilidade.

Claro que na cabeça de um empreendedor em busca de lucros ele não quer saber de processo mas sim de resultados e isso no meu ponto de vista é um pouco preocupante. Alguém pode me responder como obter qualidade no produto final se não tem qualidade no processo atual ? E se o próximo desenvolvedor a ser contratado não conseguir dar manutenção no sistema de tanta gambiarra que foi feita ? E se o próximo desenvolvedor criar a nova funcionalidade, mas quebrar uma outra antiga e isso acontecer quando o diretor do seu cliente estiver navegando no sistema ?

Estas são algumas perguntas a serem feitas para quem não é a favor do uso de testes, por exemplo e de uma possível demora no início da implantação destes em sua empresa. Acredito que essa cultura deva ser estabelecida em uma empresa para que todos vistam essa camisa e não a tirem nos momentos de incêndio como já vi acontecer em trabalhos anteriores.

Quando você passa por um projeto legado que está mal feito, cheio de bugs e problemas de estrutura, fica muito mais fácil de evidenciar e mostrar para quem for que você pode fazer algo melhor, mais organizado e com uma garantia de qualidade que são os testes. Sem contar que se conseguir fazer uma demonstração de BDD na prática com o Cucumber por exemplo, qualquer pessoa que veja a documentação(features e steps) consegue saber o que o sistema faz !

Estou na minha luta para tornar os testes que só vem para somar uma realidade. Espero que você leitor, que já utiliza esta prática, encoraje os que ainda não o fazem e você leitor que não escreve testes ainda, que procure estudar e ir atrás pois realmente vale muito a pena !

Um bom ponto de partida para quem quer começar a aprender são os railscasts do Ryan Bates que falam sobre cucumber, rspec e webrat.

Algumas outras referências:

Blog do Chelimsky (pai do RSpec)

RSpec Info

Simples Ideias – Usando o RSpec para testar sua aplicação Rails

Screencast do Anderson Leite da Caelum – Introdução à Cucumber e RSpec

Cucumber Making BDD Fun