Scrum Gathering Brazil 2009

Nesta terça (12/05) e quarta (13/05) estarei no Scrum Gathering Brazil 2009. O evento promete, com apresentações de profissionais nacionais e internacionais.

O que rolar no evento vou postar aqui ou no meu twitter.

will_paginate sem carregar ActiveRecord

Update: A solução abaixo não é mais necessária. Criei um fork do will_paginate no meu GitHub com um pequeno patch que habilita o will_paginate mesmo quando não temos o ActiveRecord carregado (obviamente, só habilita as partes que não precisam do ActiveRecord).

Para instalar:

sudo gem install gcirne-will_paginate --source http://gems.github.com

Além disso, fiz um pull request para o mislav aplicar meu patch no repositório dele. Se ele aceitar, teremos essa modificação na gem oficial do will_paginate.

Segue o post original.

O will_paginate é uma excelente gem para fazer paginação no Rails. Por default, ela pagina models do ActiveRecord. Mas também é possível paginar qualquer coleção. Basta usar o método create da classe WillPaginate::Collection.

Em aplicações Rails é possível não carregar determinados componentes do framework que não serão utilizados. Por exemplo, com a linha abaixo no arquivo config/environment.rb desabilitamos o ActiveRecord na nossa aplicação:

Rails::Initializer.run do |config|
  ...
  config.frameworks -= [ :active_record ]
  ...
end

Porém, com essa configuração o will_paginate não funciona, dando o seguinte erro:

undefined method `will_paginate'

Isso ocorre porque, ao carregar, o will_paginate insere alguns métodos em ActiveRecord::Base. Quando o ActiveRecord não está presente, o will_paginate simplesmente não carrega.  Isso é, no mínimo, estranho, já que o will_paginate funciona perfeitamente sem o ActiveRecord. Seria de se esperar que o will_paginate, nessa configuração sem ActiveRecord, carregasse normalmente, porém sem os métodos inseridos em ActiveRecord::Base (obviamente). Mas não é isso que ocorre, como podemos ver na linha abaixo no arquivo lib/will_paginate.rb da gem do will_paginate, responsável por habilitar o will_paginate:

...
if defined?(Rails) and defined?(ActiveRecord) and defined?(ActionController)
  WillPaginate.enable
end

De qualquer forma, a solução é bastante simples. Basta fazer a chamada a WillPaginate.enable_actionpack no arquivo config/environment.rb que tudo funcionará normalmente:

Rails::Initializer.run do |config|
  ...
  config.frameworks -= [ :active_record ]
  ...
  config.gem 'mislav-will_paginate',
    :lib => 'will_paginate', :source => 'http://gems.github.com', :version => '2.3.8'
end

WillPaginate.enable_actionpack

InfoFundos

Está no ar o InfoFundos, um site onde é possível acompanhar as rentabilidades de todos os fundos de investimento do mercado financeiro brasileiro. Mas este post não é sobre o site em si, e sim sobre o seu desenvolvimento.

O site é um projeto pessoal desenvolvido por mim com ruby e rails. O legal deste tipo de trabalho solo é a possibilidade de experimentar ideias, práticas, técnicas, etc.

Como não poderia deixar de ser, o desenvolvimento seguiu – e continua seguindo – os princípios e valores dos métodos ágeis. Ou seja, o site está sendo desenvolvido de forma incremental e evolutiva. A ideia é ir colhendo feedback para evoluir continuamente. Cada funcionalidade é desenvolvida da forma mais simples que poderia funcionar (simplest thing that could possibly work), com refactoring constante para deixar o código o mais limpo possível.

Uma técnica que pude usar desde o início e que ajuda a garantir a aplicação dos princípios e valores acima é o desenvolvimento outside-in sugerido pelo BDD. Cada funcionalidade é descrita por uma feature do cucumber guiada por selenium. Um passo dessa feature é escrito e, obviamente, ele falha. Então é preciso escrever apenas código suficiente para fazer este passo passar. Para isso, escrevo um spec com rspec e depois apenas o código necessário para este spec passar. Continuo assim sucessivamente, escrevendo specs e código, de fora para dentro, ou seja, das camadas mais externas até as mais internas, até que o passo esteja passando. Então, repito o ciclo continuando com o próximo passo até que toda a feature esteja passando. O ciclo completo seria algo mais ou menos assim:

feature > step > spec > implementação para spec passar > repete spec e implementação até step passar > repete step até feature passar

No final, tenho uma funcionalidade totalmente coberta por testes de aceitação com cucumber/selenium e com 100% de cobertura com rspec. Isso ajuda a garantir um código limpo, podendo ser refatorado e evoluído com bastante segurança.

Tenho diversas ideias de funcionalidades futuras para o InfoFundos e, certamente, qualquer assunto relacionado ao seu desenvolvimento será postado aqui.

Impressões da Retrospectiva Baseada em Feedback

Fizemos nossa primeira retrospectiva baseada em feedback e o resultado foi muito positivo. Acredito que conseguimos criar um ambiente de muita confiança. Todos se sentiram bem a vontade para dar e receber feedback.

Um ponto interessante que notei é que muitos comentários que normalmente ficavam guardados foram expostos de forma franca, sem que houvesse qualquer tipo de sentimento negativo de quem recebia o feedback.

Outro ponto é que eu, como Scrum Master, e o nosso Product Owner participamos normalmente. É importante que haja transparência e confiança entre todos – independente do papel que cada um exerce – já que no final das contas todos nós somos responsáveis pelo sucesso dos produtos que criamos.

O resultado de uma retrospectiva como essa é que fica bem claro para todos como nossas atitudes e ações ajudam ou atrapalham nosso trabalho em equipe. As pessoas saem realmente motivadas a melhorar. Certamente vamos repetir esse tipo de retrospectiva daqui pra frente.

Retrospectiva Baseada em Feedback

A reunião de retrospectiva ocorre ao final de cada iteração de um projeto ágil. A idéia é o time avaliar o que não está funcionando bem de forma a melhorar dali para frente. Trata-se da melhoria contínua do processo, através do ciclo de inspecionar e adaptar (inspect and adapt).

Existem diversas formas de se fazer uma reunião de retrospectiva. É interessante que a dinâmica dessa reunião seja alterada com uma certa frequência, para que não fique monótona para os participantes, o que poderia diminuir seus benefícios.

Ontem e hoje participei de um treinamento de RH. Para quem acha que esse tipo de evento é uma perda de tempo, sugiro rever seus conceitos. Fizemos uma atividade onde tínhamos que dar feedback uns para os outros. Isso me deu uma idéia para minha próxima retrospectiva.

O que fizemos na atividade (e vamos fazer na retrospectiva) é o seguinte. Cada um lista alguns pontos positivos e negativos sobre si mesmo. Uma pessoa por vez lê os seus pontos e depois só escuta enquanto as demais vão dando feedback sobre eles podendo, inclusive, acrescentar novos pontos. Prossegue-se até que todo mundo tenha dado e recebido feedback de todos os outros.

A grande sacada é a forma de dar o feedback. O que deve ser feito é ilustrar cada ponto com exemplos concretos em situações específicas de quando eles ocorreram. Não se deve fazer um julgamento pessoal do ponto em questão mas sim, no lugar disso, devem ser destacadas as suas consequências observáveis. Dessa forma, a pessoa recebendo o feedback consegue perceber mais claramente como seus comportamentos e atitudes influenciam positiva ou negativamente nas demais pessoas e nos resultados do time e, com isso, fica mais aberta a mudanças.

Retrabalho Não Combina Com Equipes Ágeis

Retrabalho significa jogar tempo, dinheiro, etc. fora. Certamente, ninguém quer isso. Para tentar evitar esse retrabalho, normalmente a solução proposta envolve especificar “bem especificado”, planejar “bem planejado”, tudo com muita antecedência. É a velha muscle memory agindo. Sabemos que isso não funciona. Simplesmente porque é impossível prever o futuro.

A solução que eu acredito funcionar é aplicar as práticas de XP. E não basta aplicar uma ou outra, temos que aplicar todas. Juntas elas promovem uma sinergia que não existe quando são utilizadas de forma isolada.

Práticas como TDD, refactoring, integração contínua, programação em par, cliente presente, sentar-se junto, design incremental garantem uma base de código saudável, com design simples. Com isso o custo de mudança permanece constante ou mesmo pode cair com o tempo.

Kent Beck viu em muitos times XP que ao longo do tempo os sistemas desenvolvidos por esses times ficavam cada vez mais flexíveis e fáceis de mudar ao invés do que estamos mais acostumados a ver, que são aqueles sistemas legados cujo custo de mudança cresce exponencialmente com o tempo. Tal afirmativa pode parecer ir contra o senso comum mas faz todo o sentido quando temos as práticas do XP aplicadas corretamente.

O custo de um time XP competente é inegavelmente alto. Mas compensa no longo prazo por permitir que sistemas não precisem ser reescritos do zero a cada x anos. Além disso, outros motivos existem para se ter um time competente. Por exemplo, evitar o custo dos Net Negative Producing Programmers. Ou seja, na minha opinião vale a pena pagar pelos melhores.

Tenho vendido a idéia de que se uma equipe ágil está funcionando bem, nunca haverá retrabalho e sim, simplesmente, trabalho.

Novos Desafios

É com muito orgulho que digo que há 2 semanas eu assumi o papel de Scrum Master da equipe onde trabalho na Globo.com, no lugar do Guilherme Chapiewski. O GC continua na empresa, com novas atribuições, mas isso cabe a ele dizer.

Posso dizer que estou bastante empolgado, mas também um pouco ansioso, com os novos desafios que vou enfrentar. Felizmente estou contando com bastante ajuda do GC além da excelente equipe com quem trabalho desde que entrei na empresa: Anselmo Alves, Bruno Carvalho, Cainã Nunes, Flávio Arioza, Leonardo Burlamaqui, Leonardo Quixadá, Tiago Motta e Vitor Pellegrino. Também posso contar com o apoio da outra excelente equipe de WebMedia, liderada pelo Marcello Azambuja: Biriba, Bruno Souza, Diogo Kiss, Juan Carlos Castro y Castro, Rafael Pereira, Tiago Mello, Tiago Peczenyj, zED.

Espero conseguir fazer um excelente trabalho!

Priorização de Histórias

Nos métodos ágeis, o Cliente ou Product Owner deve priorizar as histórias que serão desenvolvidas de forma a maximizar o Return On Investment (ROI).

Vamos supor dois cenários de projeto diferentes. Num, o cliente estipula uma data limite para o release do projeto mas não podemos prever quais histórias estarão prontas até lá. No outro, o cliente define o conjunto mínimo de histórias necessário para o release mas não temos como saber quando elas estarão prontas.

No primeiro cenário é bem claro qual a vantagem em priorizar as histórias. Quando chegar a data limite para o release, o time terá desenvolvido as histórias que agregam o maior valor para o cliente. Ficará de fora aquilo que é menos importante.

No segundo cenário poderia se argumentar que a priorização não é importante. Como todas as histórias serão desenvolvidas de qualquer maneira, tanto faz a ordem. Mas isso não é verdade. A priorização nesse cenário é tão importante quanto no anterior.

Em primeiro lugar, a decisão de só fazer o release quando o conjunto de histórias estiver pronto pode mudar. Por exemplo, pode surgir um novo projeto, mais importante, e se decidir por fazer o release com o que estiver pronto. Nesse caso, é importante que o que estiver pronto seja o que agrega mais valor.

Além disso, mesmo que a estratégia inicial seja mantida e o produto só seja lançado quando o conjunto de histórias estiver todo pronto, a priorização é importante para manter o foco no problema que se quer resolver com o produto. Isso ajuda a definir claramente para todos os envolvidos qual a visão para o produto.

Falando em Agile 2008

Nesta quinta e sexta-feira (23 e 24/10/2008) estarei em SP para o Falando em Agile, um grande evento sobre métodos ágeis. Organizado pela Caelum, contará com palestras de Guilherme Chapiewski, Phillip Calçado, Antônio Carlos Silveira e Danilo Bardusco, entre outros.

Certamente promete!

Globo Vídeos no seu iPhone

Já está no ar uma versão do Globo Vídeos otimizada para iPhone em http://m.video.globo.com. Com direito a efeitos que os usuários deste aparelho já estão acostumados, como transições ao navegar de uma página para outra, e de girar o aparelho.

Graças aos métodos ágeis que usamos aqui na Globo.com, o site foi totalmente desenvolvido em 2 sprints de 2 semanas. Quando digo totalmente, foi desde a infraestrutura necessária para produzir vídeos até o site propriamente dito.

Me arrisco a dizer que é um dos melhores sites para iPhone existentes. Certamente merece todo o nosso respeito tecnológico!

Além disso, agora também é possível assistir no iPhone os vídeos disponíveis nas versões clássicas dos sites da Globo.com, como G1 e Globoesporte. Essa funcionalidade surgiu como um projeto pessoal da nossa equipe sendo lançado agora também.

O Guilherme Chapiewski fala mais em seu blog tanto sobre o Globo Vídeos Mobile quanto sobre os vídeos para iPhone nas versões clássicas dos sites Globo.com, inclusive com screenshots.