No Brasil, os servidores na Linode foram abertos às 21hrs de sexta-feira e fecharam às 22hrs de domingo (por causa do nosso horário de verão). A Gonow disponibilizou espaço, infra-estrutura, alimentação para 6 equipes (uma de última hora). Participaram as equipes Acts as Code Monkeys on Steroids, Goweb, To Loco, Mouse Over Studio, Cangaceiros (um dos integrantes, os outros estavam em Fortaleza) e Sampa on Rails (metade da competição, depois foram pra casa). Vejam as aplicações deles:
Como disse, mais de 30 equipes participaram. Eu não vi ainda todas as aplicações, mas algumas que eu vi e achei legais são:
Tem vários outros legais, então veja a lista de participantes brasileiros e vote neles! E, claro, avalie também as outras centenas de aplicações no site do Rumble. Na página de cada equipe está listado os participantes bem como uma descrição do aplicativo, as principais tecnologias utilizadas e assim por diante.
O Rumble
A experiência do Rumble é excelente. Quando falamos em 2 dias – 48 horas – parece um tempo curto demais para se fazer uma aplicação. Mas na realidade é bastante tempo. Pense que uma semana útil, de 5 dias com 8 horas de trabalho, são exatamente 40 horas. Considerando 8 horas de descanso, 48 horas é tempo mais do que suficiente para se fazer uma aplicação minimamente funcional.
O Rails Rumble é um grande experimento social. Nesse período de 48 horas, temos quase 300 equipes auto-organizadas praticando agilidade de alguma forma. Claro, nem tudo sai conforme a teoria. Muitos participantes acabaram desistindo de última hora, muitas idéias tiveram que ser simplificadas ou funcionalidades tiveram que ser deixadas de lado, conflitos. Fora os problemas técnicos de última hora como ficar sem internet durante algum período e assim por diante. Com tanta gente, muita coisa pode acontecer. Mas a intenção não é ser perfeito, é ser ágil: fazer o mínimo possível que trás mais valor num espaço restrito de tempo.
Nós, da comunidade Rails, temos diversas práticas consideradas comuns, como fazer testes, automatizar os testes, automatizar o deployment, reuso a partir de gems e assim por diante. Claro, muitos pularam para o Extreme Go Horse totalmente ou parcialmente. Não dá para ser 100% perfeito, mas acredito que a maioria das equipes, ou quase todas, pelo menos tentaram começar seguindo as boas práticas. E justamente porque o tempo é curto e limitado, você não vai querer perder as últimas horas debugando erros de regressão e coisas quebrando. Muitos poderiam imaginar justamente porque o tempo é curto que pode tudo de qualquer jeito. Está errado: justamente porque o tempo é curto é melhor ser prudente desde o começo para não correr atrás do próprio rabo depois. Tudo depende da complexidade da aplicação, do entrosamento da equipe, das tecnologias utilizadas e assim por diante.
Algumas coisas que notei é que, obviamente, não dá pra fazer aplicações muito grandes ou hiper complexas em tão pouco tempo. Por isso é mais importante ainda definir logo de começo um backlog priorizado, pra começar fazendo o que trás mais valor primeiro. A maioria das equipes provavelmente terminou fazendo menos do que imaginava inicialmente. Mas isso não tem problema porque todo projeto de software é assim: você nunca termina com o que imaginou, e muito que você nem imaginava no começo foi implementado no projeto. É assim que funciona software. Quem se planejou melhor, começou fazendo o que era mais importante primeiro, provavelmente terminou com um aplicativo mais satisfatório. Quem se planejou pouco, terminou fazendo menos do que gostaria ou nem terminando.
Não lembro que disse isso primeiro, mas o @fabiokung twitou isso algum tempo atrás, eu concordo e acho que vale aqui também:
“Ação sem planejamento é hobby e planejamento sem ação é fantasia.” – (sem fonte)
Outra coisa é a composição das equipes: podia se inscrever desde equipes solo (somente um), até 4 pessoas. Não existe uma receita, claro, e varia de projeto pra projeto, mas acho que o principal é ter pelo menos um bom designer criativo, um cara bom de interface (transformar o design em HTML) porque um dos gargalos é justamente fazer um HTML, CSS bem estruturados, que sejam compatíveis com a maioria dos browsers, e isso dá trabalho. Da parte Rails praticamente basta 1, no máximo 2 desenvolvedores. Mais do que isso será um desperdício. E um deles deve ter pelo menos o mínimo de noção de administração de sistemas, pois o servidor é entregue zerado e a equipe precisa instalar e configurar componentes como o Apache, MySQL, Passenger. Mas é uma tarefa razoavelmente trivial de se fazer hoje em dia.
O ideal é ir lançando o aplicativo no servidor o tempo todo, desde o começo, mesmo com o aplicativo inacabado. Deixar pra instalar no servidor só nas últimas horas é um risco alto demais. Além disso colocar em produção logo e avisar os amigos, significa mais chances de encontrar bugs que ainda podem ser corrigidos. Deployment contínuo é importantíssimo, tanto quanto ter testes automatizados.
Auto-Organização
Para você, que é gerente ou não-desenvolvedor, entenda este cenário: você provavelmente acredita que a única forma de conseguir entregar software é fazendo um levantamento detalhado de requisitos, criar um planejamento de recursos, dividir as tarefas, considerar o paralelismo de atividades num gantt chart para otimizar a produtividade e assim por diante. Mais do que isso, você provavelmente já entenderia que 48 horas é curto demais pra fazer algo sério.
Além disso você precisa assinalar um gerente de projetos, no mínimo um coordenador, para acompanhar o andamento e ajustar o fluxo de tarefas e otimizar a produtividade da equipe.
Entenda que o Rails Rumble não tem esse papel de gerente, ou coisa parecida. As equipes literalmente não tem chefe! Elas precisam, obrigatoriamente, se auto-organizar. Eles precisam definir eles mesmos a prioridades, quem vai fazer qual tarefa em qual momento, como revezar, até mesmo coisa externas como se todo mundo vai dormir no mesmo horário ou se vão revezar alguns dormindo enquanto outros trabalham.
Veja que o Rumble é bem rígido: 48 horas são 48 horas, e ao final do período não tem exceção pois tudo fecha e não tem perdão. Quem se enrolou e por alguma razão bizarra da natureza deixou pra fazer o deployment só na última hora provavelmente teve problemas. E auto-organização não significa nem caos completo e nem que tudo vai dar certo, significa que os membros vão se comunicar entre si o tempo todo, adaptando e reorganizando as coisas à medida que se vê necessário. Todo gerente deveria acompanhar as equipes trabalhando no Rumble para minimamente entender como é a dinâmica de equipes verdadeiramente ágeis.
Uma coisa que toda equipe deve ter enfrentado é ter imaginado uma aplicação de um jeito e, durante o desenvolvimento, descobrir que algumas funcionalidades não faziam sentido, ou que não daria tempo, ou que algumas coisas eram menos importante do que se imaginava inicialmente. A exploração, descoberta e consequente reorganização do projeto acontece o tempo todo durante o desenvolvimento. Além disso, para quem é agilista teórico, em 2 dias inteiros não é prático para a maioria ficar se preocupando em rituais, micro-reuniões e tudo mais. Os rituais precisam ser substituídos por comunicação direta, frequente, aberta e constante. Em 2 dias não tem tempo pra politicagem, interesses externos, influências externas como um stakeholder que não sabe o que está fazendo. Portanto a comunicação provavelmente funciona bem melhor numa equipe do Rumble do que numa equipe num projeto tradicional de uma empresa.
Conclusão
O Rails Rumble é uma excelente idéia que deveria ser copiada por todas as comunidades de desenvolvimento. Mais ainda, deveria ser entendida por empresas que desenvolvem software. O Rumble é um excelente laboratório social onde muito pode ser testado e entendido. Onde mais você vai encontrar centenas de pessoas trabalhando todos dentro dos mesmos limites mas usando dezenas de técnicas diferentes?
E o Rumble também é uma excelente forma para dar algumas respostas diretas pra perguntas retóricas do tipo: “Quão difícil é fazer e colocar uma aplicação Rails em produção em pouco tempo?” Mesmo que você não seja desenvolvedor, navegue pelas aplicações criadas, você vai começar a entender o que é possível fazer com equipes de 4 pessoas ou menos em cerca de 1 semana de trabalho. É uma ótima referência: se seu fornecedor disser que leva 1 mês para fazer um projeto muito parecido que você viu no Rumble, feito em 48 horas, vai entender quem está enganando quem.
No final, na Gonow o Rumble foi muito legal. Foram mais de 100 latinhas de energético, 15 pizzas, 20 sanduíches, mais 2 coffee-break diários. Foram mais de 2000 visitantes nos dois dias assistindo o streaming de vídeo em tempo real (tivemos um pequeno perído de algumas horas fora do ar por problemas técnicos). Além de mais de 150 views em cada vídeo que publiquei no YouTube! Agradecimentos à Gonow pelo suporte ao evento e à e-Genial que, novamente, nos ajudou no live streaming com a tecnologia do Treina Tom.
Parabéns a todos os participantes do Rumble, você demonstraram mais uma vez o espírito de colaboração, comunidade, compartilhamento de conhecimento, camaradagem e espírito esportivo. Qualidades que todo bom desenvolvedor de software deveria ter obrigação de ter.