Adolfo Sousa

Na última semana, eu e mais três Locawebers (Antônio Marques, Fernando Amorim e Nando Vieira) estivemos em Baltimore para a Railsconf 2010. Com mais de 1000 participantes, incluindo grandes expoentes de importantes comunidades de software, é a maior conferência de Ruby on Rails do mundo.

Durante os 4 dias do evento, muitas palestras aconteceram. Mais importante do que escrever sobre cada uma delas, é falar um pouco sobre algumas novidades e sobre o que mais me impressionou na conferência:

• Rails 3 - talvez a maior expectativa da comunidade fosse o anúncio do lançamento do Rails 3. Ela não foi completamente atendida, porém foi lançada a versão beta 4 do framework. Adicionalmente, Gregg Pollack anunciou uma série de screencasts explicando as novidades da versão 3. Vale a pena conferir: http://rubyonrails.org/screencasts/rails3/

• Keynotes - fiquei impressionado com a quantidade e com a qualidade da grande maioria deles. Destaque para a apresentação do Yehuda Katz sobre “fazer”, dando dicas de como contribuir para projetos open source (http://en.oreilly.com/rails2010/public/schedule/detail/14132). Acredito que todos os keynotes podem ser encontrados no site oficial do evento: www.railsconf.com

• Palestras - assisti a algumas palestras ruins, algumas boas e outras excelentes. Entre as melhores a que assisti, estão as seguintes:

- Rocket Fueled Cucumbers: sobre como escalar testes de aceitação. A apresentação foi muito bem preparada e todas as ferramentas e dicas dadas pelo Joseph Wilk foram pertinentes. Vocês podem conferir os slides aqui e a gravação da mesma palestra apresentada na Scottish Ruby aqui

- Ruby on Rails Tasty Burgers: sobre os componentes, as diversas partes que formam o Rails. Aaron deu uma palestra muito divertida, didática e informativa. Além da excelente palestra, ele também recebeu um Ruby Hero Award

- Making Rails Really RESTful with Restfulie: quase que diariamente em listas ou em conversas, e também durante a conferência, vejo muita gente com conceitos incompletos ou equivocados a respeito de Rest. Sem dúvida, um dos desafios de quem defende e luta pela adoção deste estilo arquitetural é acabar com estes equívocos; foi um pouco do que fez o Fábio Akita. Além de explicar muito bem alguns conceitos, ele mostrou o que no Rails está e o que não está de acordo com as definições de Rest. Ele também falou um pouco sobre o projeto Restfulie (http://restfulie.caelumobjects.com/), uma excelente e inovadora iniciativa tocada principalmente pelo Guilherme Silveira da Caelum

• Birds of a Feather - as BOF na RailsConf acontecem todos os dias, durante o dia todo. O valor de conversar e programar com as pessoas que desenvolvem importantes projetos é impagável. Elas estavam lá o tempo todo e dispostas a conversar e mostrar o seu trabalho. Admirável.

• A comunidade Brasileira - na minha opinião, a força e importância da nossa comunidade está sendo reconhecida e valorizada pelo mundo inteiro. Por exemplo: o Fábio Akita deu uma das melhores e mais elogiadas palestras da conferência. O Guilherme Silveira e o Cauê Guerra fizeram um BOF a respeito do Restfulie e pudemos perceber que o projeto é o que há de mais avançado e inovador no assunto. Muitas pessoas vinham conversar com o George Guimarães da PlataformaTec sobre o Devise. Um dos palestrantes mostrou e elogiou umas das muitas gems criadas pelo Nando Vieira, nosso colega aqui da Locaweb. Muitas pessoas vinham falar conosco da Locaweb sobre o Rails Summit e sobre a comunidade Rails no Brasil. E, pra terminar, o José Valim foi um dos Ruby Heroes deste ano. Muito bom, não?

Já faz algum tempo que não tenho tanta paciência para ficar discutindo metodologias ágeis para desenvolvimento de software. A minha cabeça de alguma forma passou a pensar que tudo se resume a aplicar bem o manifesto ágil. E isto, por si só, não é nada fácil. Exige muita disciplina, capacidade, atenção e profissionalismo. Nenhuma metodologia, ferramenta ou gerente vai resolver o real problema do nosso mercado: escrever software útil e de qualidade.

Danem-se os selos CMMI, as certificações do PMI e da Scrum Alliance, os programadores que enchem currículos de siglas e código de sujeira. O que vai resolver o nosso problema é gente competente, disciplinada (no sentido dado pelo Uncle Bob no seu keynote da RailsConf), capaz de ouvir o cliente e criar uma relação verdadeira de parceria com ele, com características para evoluir constantemente. Se você ou a sua empresa são capazes de fazer isso bem, não se preocupe em dar um nome para os métodos que você usa para fazer o seu trabalho. É feio sair por aí dizendo que aplica scrum (ou qualquer outra coisa da moda), encher o bolso de dinheiro e se esquecer os princípios básicos do manifesto ágil.

Esta introdução longa é para desabafar a raiva acumulada pelo monte de besteiras que eu ouvi em algumas palestras no Scrum Gathering 2009. Muita gente já escreveu e/ou tocou em pontos polêmicos sobre o evento. Quero dar os meus pitacos, então vamos ao que mais me irritou naqueles dois dias:

• Times auto-gerenciáveis - pelo menos 2 palestrantes (Ricardo Vargas e Fábio Câmara) afirmaram categoricamente que nunca viram um time capaz de se gerenciar. E somente isso. Não contaram alguma experiência ou analisaram o motivo pelo qual isso é impossível no ambiente deles. Este é um assunto muito interessante e qualquer discussão é válida.
• Ken Schwaber - imagine que você vai ter uma aula de futebol com o Ronaldinho Gaúcho e o cara gasta o tempo falando que no futebol a bola é redonda, os times têm 11 jogadores, o objetivo é fazer o maior número de gols, etc, etc, etc. Pois é, assim foi a palestra de um dos criadores do scrum. O sujeito ficou quase uma hora falando o básico e o óbvio, fez uma brincadeira mais do que manjada para falar de “comando e controle” versus “times auto-gerenciáveis” e finalizou anunciando que a Scrum Alliance vai lançar o treinamento para CSD (Certified Scrum Developer) e que este vai ser baseado em ferramentas da Microsoft. Precisa falar mais alguma coisa?
• Fábio Câmara - a palestra do Fábio foi a mais polêmica, ainda mais sabendo que ele é um CSP (Certified Scrum Practitioner). Li o título “Usando scrum com o Visual Studio Team System” e fiquei curioso para saber o que faz alguém precisar tanto de uma ferramenta para usar scrum. No meio da palestra o Fábio algumas afirmações, dentre elas: “eu questiono o uso de testes, principalmente os unitários, em projetos time-driven”; “eu tinha um estagiário que eu chamava de controller porque ele ia todo dia de manhã de mesa em mesa perguntando para o desenvolvedor se ele estava fazendo a tarefa que ele deveria estar fazendo. O VSTS me diz isso, uma vez que ele cria um link entre o requisito e o pedaço de código que foi escrito para atender aquele requisito. Eu também consigo saber quem escreveu cada linha, porque quando você pergunta numa sala ‘quem escreveu essa linha aqui?’ fica todo mundo assobiando”; “é incrível como o princípio de pareto se aplica em quase todos os projetos de software. 20% das pessoas fazem 80% do trabalho”; “os desenvolvedores, no final do dia de trabalho, fazem check-in do que eles produziram. No VSTS eu consigo ver cada check-in e passar a mão no telefone pra perguntar por cara lá em Recife porque ele subiu só 25 linhas de código quando a média dele era de umas 200″; “o scrum master e responsável por distribuir as tarefas para o time”. Logicamente algumas pessoas começaram a questionar tudo isso e ele descreveu um cenário para ‘justificar’ tudo isso: “imagine uma equipe grande. Eu já gerenciei equipes com 60 pessoas, algumas trabalhando em outros estados, etc …”. As minhas sugestões para o Fábio são as seguintes: 1) demita umas 50 pessoas da sua equipe (olha o problema do princípio de pareto sendo resolvido) e forme um time com os 20% que fazem 80% do trabalho e no qual você possa confiar e não controlar (opa, pode mandar o controller embora também). Pare de procurar culpados, isso não resolve nada, é desperdício. Se alguém fez alguma coisa errada no código, esse alguém foi o time e ele mesmo resolve (você já deve ter ouvido falar de propriedade coletiva do código e programação em par). Você não vai precisar ficar bancando o detetive pra descobrir quem foi o infeliz que escreveu a linha 1567 da classe XXXX ou bancando o leão-de-chácara do repositório. Deixe os seus programadores escreverem muitos testes e automatizá-los. 2) se vocês estão sem tempo para escrever os testes, peça a colaboração do seu cliente; explique que o time precisa escrever testes para entregar um produto de qualidade, trabalhem com ele na priorização das histórias, mostre as vantagens de desenvolver um produto iterativamente, melhorando continuamente, respondendo às mudanças. 3) pare de valorizar mais o Visual Studio do que a sua equipe. 4) nunca, jamais, de forma alguma, esqueça do manifesto ágil 5) e, POR FAVOR, pare de falar que o que você está fazendo é scrum.

Na minha opinião, o evento contou com palestras muito boas (Juan Bernabó, Alexandre Magno e Luiz Cláudio Parzianello), mas estes 3 fatos citados bastaram para fazer do Scrum Gathering 2009 - Brazil e da Scrum Alliance um baita fiasco.

Além da excelente palestra do Obie Fernandez, eu assisti a outras memoráveis apresentações no Rails Summit 2008. Aqui vai a trilha que segui no evento e o que mais me impressionou em cada uma delas:

• David Heinemeier Hansson (DHH) - O criador do Rails participou do evento respondendo a perguntas da platéia por vídeo-conferência. A meu ver, a pergunta mais interessante foi a respeito de como a equipe que mantém o framework lida com as sugestões de novas features. A resposta pode ser interpretada como “nós respiramos Lean”; DHH contou que eles simplesmente incorporam ou implementam somente o que o framework necessita e se faz prioritário. Se não é necessário naquele momento, não fará parte do Rails, não importando se está na moda ou qualquer outra coisa.
• Chad Fowler - o escritor de “My job went to India” fez uma palestra muito motivadora. Com o título “Being Remarkable”, Chad deu dicas sobre como nós, desenvolvedores de software, podemos nos destacar. Dentre as dicas, gostei das “machuque-se” e “seja o pior músico da banda”. A primeira diz respeito a nos colocarmos em situações em que nossos conhecimentos, habilidades e capacidades são postos à prova. A segunda nos diz que trabalhar com programadores melhores que nós é uma excelente maneira de aprender e evoluir. Eu nunca havia visto uma apresentação do Chad Fowler, mas agora posso dizer que é sensacional.
• Dr. Nick - muito boa a apresentação desta figura simpática e brincalhona. “Path to awesomeness” é a palestra a que eu gostaria de ter assistido, juntamente com a “Being Remarkable” do Chad Fowler, no comecinho da minha curta carreira de programador. Ele, basicamente, deu dicas a respeito de como ser um bom profissional na nossa área. São elas: 1) aprenda sobre sistemas de versionamento de código (svn e git, atualmente) 2) aprenda a testar 3) comece um blog 4) aprenda a criar aplicações 5) melhore o seu código. Como julgo estas dicas muito importantes e tenho acréscimos a fazer, vou falar mais sobre isto num próximo post.
• Jay Fields - falou sobre a imaturidade dos testes de desenvolvedores. O palestrante fez uma interessante análise das mais famosas ferramentas de testes existentes para ruby/rails. Eu não conhecia o Jay Fields nem tenho muita experiência com ruby e rails, mas me pareceu que ele sabia muito bem o que falava. Expôs claramente pontos positivos e negativos de cada ferramenta, bem como suas opiniões. Respondeu a perguntas e não ficou em cima do muro ao citar quais são as ferramentas que ele usa e prefere: para testes unitários, Expectation. Para testes integrados, Rspec. Para smoke tests, Selenium. Outro ponto importante que o Jay Fields fez questão de reafirmar repetidas vezes é que a sua suíte deve rodar muito rapidamente. Para ele, uma suíte que demora mais de 1 segundo já é problemática e deve ser melhorada.
• David Chelimsky - David é o atual mantenedor do Rspec e falou, na sua primeira apresentação, sobre BDD. Quando comecei a ler sobre BDD, ainda estava tentando fazer TDD. Lá no comecinho, tinha muita dificuldade para começar a escrever um teste. Sempre parava e falava “e agora? que teste eu escrevo? o que eu faço?”. E o que me ajudou muito a vencer esta limitação foi escrever os meus testes à BDD com “should…”. Pra mim foi mais fácil desta maneira porque me ajudava a pensar a funcionalidade de fora pra dentro. Era mais fácil modelar e começar a escrever desta forma. E o David falou disso na sua excelente e didática a palestra.
• Danilo Sato - falou das motivações que o levaram e das dificuldades que teve quando começou a escrever testes automatizados para os seus programas. Algumas das importantes lições citadas pelo Danilo são: testes grandes são difíceis de manter (escreva testes pequenos no estilo arrange-act-assert), é bom cobrir a funcionalidade do ponto de vista externo, código de teste também é código e cuidado com mocks para libs externas.
• Vinícius Manhães Teles - a apresentação foi dividida com o Carl Youngblood da Surgeworks, que falou sobre o ambiente rails aqui no Brasil. Eu nunca tinha assistido a uma palestra do Vinícius, apesar de já o conhecer pelo seu livro de XP.  Foi uma ótima apresentação, mas o que me impressionou mesmo foi ouvi-lo falar sobre empreendedorismo. É impossível descrever ou expressar o valor daquilo falado por ele. É admirável o que o Vinícius fez como pioneiro e evangelizador de XP e vem fazendo, com o pessoal da Improve It, ao inovar o nosso mercado de software.

A primeira edição do Rails Summit foi um incontestável sucesso pelo valor de tudo aquilo falado pelos palestrantes. Tivemos verdadeiras aulas de empreendedorismo, inovação, idéias e agilidade. Tenho certeza de que todos os participantes do evento aprenderam muito. Mais uma vez, meus parabéns à Locaweb e ao Akita pela histórica realização.

Vou relatar aqui uma das palestras com as quais mais me impressionei no Rails Summit 2008, brilhantemente organizado pela Locaweb e pelo Fábio Akita. Pra quem não o conhece, Obie Fernandez foi um dos pioneiros e responsáveis pela adoção do Ruby on Rails na Thoughtworks, escreveu o famoso “The Rails Way” e fundou a Hashrocket. Esta figura simpática, didática e inovadora nos presenteou com o Keynote de encerramento do evento.

Obie listou os 4 princípios do Manifesto Ágil e explicou o que faz para aplicá-los em sua empresa. Em suma, foi uma aula a respeito de agilidade e boas práticas para quem já trabalha ou pretende trabalhar seguindo esta filosofia. Com vocês, o “Hashrocket Way”:

1. Valorizar indivíduos e interações mais do que processos e ferramentas

Nesta parte da apresentação, ele falou muito a respeito das pessoas com as quais trabalha. Mostrou muitas fotos do seu escritório (com vista para o mar), das reuniões diárias e alguns vídeos engraçados do pessoal se divertindo enquanto trabalhava. O mais marcante, porém, foram as suas idéas a respeito de pair-programming. Para Obie, é fundamental ter um monitor com dois teclados e dois mouses para se programar em par. Isto impede que a pessoa mais imperativa domine o teclado e força a participação das duas pessoas. Falou que uma pessoa pode escrever um teste e a outra o pedaço de código para passar aquele teste. Ficou claro que ele enxerga esta prática, quando bem aplicada, como um bem para as pessoas, já que elas aprendem e crescem com mais rapidez, as tornam mais produtivas e, por conseqüência, realizadas. Outro ponto interessante é o número de pessoas nos seus times: segundo Obie, em um time com mais de 4 pessoas você já pode ter problemas de comunicação e perder o auto-gerenciamento. Seus times são de 2 ou 4 pessoas. E sobre contratações, ele contou que publica um post no seu blog, as pessoas respondem, e ele convida algumas para trabalhar para eles por 1 semana. Ele não se importa se o sujeito tem bilhões de diplomas e títulos, se tem 30 anos de experiência ou se já passou por muitos empregos. Ele quer ver como a pessoa se comporta trabalhando num projeto real e em par. Ele não espera perfeição, mas a candidato deve ser capaz de trabalhar em pares, aprender rapidamente e lidar com a pressão de um projeto verdadeiro.

2. Valorizar software funcionando mais do que documentação extensa

Aqui ele deu o recado citando a divertida palestra de um rapaz chamado Brian Liles: TAFT - Test All The Fucking Time. É bem curta e divertida, assistam!

3. Valorizar a colaboração do cliente mais do que (re)negociação de contrato

Ele mostrou uma espécie de contrato em que o cliente não é obrigado a pagar pelo software caso não fique satisfeito. Porém, deixou bem claro que é preciso se proteger. Se o cliente não é obrigado a pagar, ele também não pode processar a Hashrocket e pedir uma indenização maior do que pagaria. Depois, mostrou fotos de alguns clientes realmente trabalhando com a equipe em alguns projetos especiais que eles chamam de “3, 2, 1, launch”. São projetos que eles fazem em 3 dias, desde que o cliente esteja presente e que eles tenham a parte visual da aplicação já definida; este é o único caso em que ele não segue uma prática da XP (design simples).

4. Responder às mudanças mais do que seguir um plano

Neste final da apresentação, ele mostrou a ferramenta Pivotal Tracker. Falou que sempre estimam as tarefas em pontos (com tamanho máximo de oito) e também sobre a importância das reuniões diárias.

Como não consegui os slides, estou escrevendo a partir daquilo que lembro e anotei, e com a ajuda do post que acabo de ler no blog do próprio Obie Fernandez. Pretendo escrever mais a respeito das outras palestras a que assisti e gostei no Rails Summit 2008.

Até mais!!!