Voto Como Vamos: Ágil, Open-Source e One-Click Deploy sem custo

O projeto Voto Como Vamos foi uma das coisas que me marcou esse ano. É simplesmente fantastico ver o potencial de pessoas apaixonadas pelo que fazem em ação. Digo isso porque esse projeto foi desenvolvido com 100% de trabalho voluntário e com um objetivo muito nobre: A conscientização política.

No início eram quatro ou cinco pessoas de um grupo que queria melhorar de alguma forma o modo como candidatos e eleitores se relacionavam em Porto Alegre, o grupo Porto Alegre Como Vamos e a ThoughtWorks cedeu espaço para que eles pudessem falar com a gente sobre esse projeto estranho de nome mais estranho ainda, o Voto Como Vamos.

No início, vimos o vídeo abaixo e alguns dos membros do Porto Alegre como vamos falaram com a gente sobre alguns detalhes e expectativas que eles tinham com o projeto, entre eles, os fatores mais críticos do projeto… custo deve ser baixo e o release deve ser em quatro semanas, integração com sistemas do governo, gestão do cadastro dos candidatos, integração com redes sociais…


Resumindo o vídeo, o Voto Como Vamos é um projeto desenvolvido por um grupo apartidário chamado Porto Alegre Como Vamos, formado por jovens apartidários da sociedade civil, que visa melhorar a cidade de Porto Alegre. O objetivo desse projeto é aproximar candidatos e eleitores criando um canal de comunicação colaborativo através de redes sociais, principalmente o Facebook.
Inception do Projeto

Assistimos o vídeo a acima e muitas dúvidas apareceram, sobre a viabilidade do projeto, sobre a fundamentação, sobre os objetivos, sobre a aceitação do projeto tanto pelos candidatos quanto pelos eleitores e eu confesso que sempre fui muito incrédulo sobre esse juntar política e redes sociais. É uma ideia muito delicada, pois envolve política.

Mas… alguns minutos de conversa com essas pessoas eram o suficiente para convencer o mais céticos e apolíticos :), além disso, a proposta de projeto parecia muito interessante tecnicamente, com um domínio novo e totalmente diferente e com techstack 100% green field, tanto para desenvolvimento quanto para testes.

Aceitamos o desafio de fazer o projeto e claro, ao bom e velho modo ágil de fazer as coisas, fizemos a inception do projeto em um sábado. A empolgação tomou conta de todo mundo e dezenas de features surgiram. Lembro que todos na inception opinaram sobre dezenas de aspectos e no final tínhamos um product backlog grande e cheio de features interessantes.

Conversamos com essas meninas que não entendiam nada de ágil, de desenvolvimento de software ou seus processos, nada de tecnologia e pensamos que os desafios só estavam começando. Como consultores, todos vivemos experiências com POs experientes de grandes empresas que praticam “ágil” em que definir um MVP é uma tarefa ardua, cansativa e quase nunca possível em duas ou três semanas de inception, imagine só definir um MVP com um PO que não sabia o que é um PO.

Equipe Voto Como vamos

Ainda nesse sábado falamos sobre a stack técnica do projeto, e três linguagens de programação apareceram, PHP, Ruby e Python. Cada uma delas tinha a sua vantagem e conversamos bastante sobre elas. Enquanto o PHP seria mais fácil de achar mão de obra acessível dentro do budget que o POA Como Vamos tinha para o projeto, Python seria uma tecnologia interessante para todos na equipe e chamaria mais voluntários e Ruby por sua vez, é uma linguagem quase tão interessante para o pessoal quanto Python e fácil de codificar.

Optamos por ruby pois era uma linguagem que a maioria das pessoas envolvidas até então conheciam e  assim seria mais fácil de manter a app durante o desenvolvimento, além disso a maioria das pessoas envolvidas no projeto tem grande experiência com Ruby, o que ajudaria na velocidade das entregas, nas configurações básicas de CI e teste e principalmente na resolução de problemas que apareceriam, uma vez que nosso “go live” era muito próximo e uma linguagem nova para muitas pessoas poderia ser um agravante na resolução rápida desses problemas.

O Desenvolvimento

O desenvolvimento não foi fácil. Eu mesmo trabalhei a maior parte do tempo como Devops e Developer ao invés de QA, e essa foi uma das coisas mais interessantes na minha opinião. Ninguém no projeto era o Manager, o Dev ou o QA, todos trabalhávamos em roles diferentes o tempo todo, de acordo com a demanda. As próprias POs testavam o produto, e alguns dos BAs também ajudavam nessa tarefa. Não trabalhamos com iterações, mas com deadlines curtos e com entregáveis muito pequenos.

Foram dois meses de desenvolvimento, quase 300 builds, mais de 40 cenários e mais de 280 steps de teste automatizados, mais de 150.

Como o projeto foi desenvolvido 100% com trabalho voluntário, tivemos muitos problema com pessoas que tiveram que viajar durante o desenvolvimento, eu mesmo fiquei quase uma semana praticamente fora do projeto. Se não fossem os testes automatizados, provavelmente o projeto não teria saído, já que não tínhamos tempo e nem pessoas focadas para testes de regressão. Outro problema do projeto é que inicialmente ele foi desenhado para funcionar dentro do canvas do Facebook, o que tornava a integração com o mundo externo muito complexa. Além disso, como é uma app com finalidade política, tivemos muita preocupação com segurança e transparência durante todo o desenvolvimento, além disso tivemos que desenvolver um modelo de importação do TRE genérico assim como várias features, principalmente voltadas para o layout e idioma, de forma a facilitar a distribuição da app para outras cidades.

Stack Técnica

Para gestão de configuração optamos pelo GIT e o repositório foi o Github. Como ferramenta de CI optamos pelo Travis-ci, serviço gratuito na internet que funciona da mesma forma que o Jenkins e Hudsonmysql como banco de dados já que nosso modelo de negócio é muito mais relacional, embora o banco preferido fosse o MongoDB. Para hospedar a aplicação optamos pelo Heroku por ser uma infraestrutura segura, relativamente barata e flexível, onde criamos os ambientes de teste, stage e produção. Para comunicação usamos o Campfire e o Facebook, como track de bugs e stories  usamos as issues do Github e como task wall usamos o Linoit. Os sistemas operacionais eram Linux e OSX. Para testes de aceite usamos Cucumber com Capybara e unit tests RSpec. Ainda usamos alguns frameworks especiais como o Koala, um wrapper para interação com a Facebook Graph API, sunspot-solr para pesquisa textual, FactoryGirl para fixture replacement e slim para html.

Repositório: https://github.com/thoughtworks/voto-como-vamos
Produção: http://www.votocomovamos.com.br (testes no ambiente de testes por favor :) )
Teste: http://teste.votocomovamos.com.br (fique a vontade para testar)

O projeto continua

Agora estamos ajudando outras cidades a implantar o Voto Como Vamos e estamos melhorando o projeto. Recentemente tivemos um workshop de UX para QAs/Testers na ThoughtWorks, com a visita dos Interaction Designers Danilo Barros e  Pedro Belleza da Hewlett-Packard onde identificamos dezenas de oportunidades de melhorias e alguns bugs de baixo e médio impacto para o projeto. Atualmente estamos em processo de correção e a aplicação tem deploys com melhorias e correções todos os dias.

Esse projeto foi realmente fantástico. Não só porque foi em ruby, porque os testes foram bem elaborados, porque tivemos a oportunidade de reproduzir um pouco de continuous deployment usando ferramentas, recursos e serviços free e open-source, mas principalmente porque o time que formamos se tornou muito amigo durante esse projeto, porque da muito orgulho ver candidatos e propostas de verdade na plataforma e porque pudemos compartilhar e contribuir para uma ideia e um sonho com pessoas que doaram noites, fins de semanas e feriados paraque o projeto acontecesse.

No final do projeto uma surpresa. durante o lançamento do projeto recebemos esse agradecimento das nossas product owners.

 

Projetos sociais e projetos open source são uma ótima oportunidade de aprender coisas novas, de praticar nossas skills técnicas e de ampliar nossa rede de contados profissionais. Além disso, tanto os projetos open source quanto os projetos sociais colaboram de forma positiva para a sociedade. A melhor sensação não é nem o sentimento de missão cumprida, nem o conhecimento agregado pelo projeto, mas saber que de alguma forma, usando o seu conhecimento e sua vontade, você colaborou para tornar o sonho de alguém realidade e para ajudar pessoas e esse sentimento vale mais do que dinheiro :).

Projetos desse tipo, muitas vezes podem absorver mais riscos do que projetos das empresas que trabalhamos, e neles podemos testar aquela ferramenta nova que estudamos mas não podemos usar na nossa empresa, nele podemos tentar usar uma abordagem diferente do que estamos acostumados.Leve essa ideia para a empresa que você trabalha, junte amigos e procure oportunidades de desafiar as suas habilidades. O nosso país é cheio de problemas sociais e com certeza tema alguma coisa perto de você que pode ser resolvida ou pelo menos melhorada com software.

Bons testes :)

 

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

One thought on “Voto Como Vamos: Ágil, Open-Source e One-Click Deploy sem custo

  1. galera,
    estarei testando o projeto, me chamo juliano trabalho à 4 anos com testes de acessibilidade, se precisaremd e apoio nos projetos, só falar.
    sabemos que projetos deste gênero, reqeurem acessibilidade à pessoas com deficiencia, como eu que sou cego, e já atuo na área de qa.
    meu email: julianotrovao2@gmail.com.skype: ministro.juliano.
    grande abraço e espero poder ajudar em projetos futuros!

Leave a Reply