Usando o Trac para coordenar seu desenvolvimento ágil
==============================================================
Update: não estamos mais usando o Trac. Apesar do mesmo ser ótimo, passamos a usar o Redmine. Em grande parte a mudança se deve a falta de suporte à nossa nova menina dos olhos: o Git. É até um pouco pretencioso falarmos em “nossa nova menina dos olhos”, porque o Git já é um verdadeiro hit. Além disso, 2 outros fatores pesaram: o fato do Redmine ser feito em RoR, o que dos upgrade coisas simples, e uma aderência maior aos padrões de projeto descritos no PMBok.
==============================================================
Pequena pausa nas melhorias do VoteBolsa pra escrever um pouco no blog. Primeiro post do ano. Pensei até em colocar um nome diferente: “Trac é coisa linda de deus“. Ok, resolvi ser mais profissional e mostrar mais do que a organização do Trac. Queria também mostrar como estamos utilizando ele para coordenar o desenvolvimento de forma ágil.
O Trac é uma aplicação open source, feita em Python, e com front-end inteiramente web, que ajuda no gerenciamento do desenvolvimento de projetos de software e no rastreamento de correções de bugs.
Só pelo gerenciamento das correções de bugs (comparável ao notório Bugzilla) o Trac já mereceria destaque. Mas, ao integrar um controle de Tickets (tanto de bugs quanto para aprimoramentos e o que mais for definido, como tarefas) ao controle de versões já existente (como Subversion ou o Git) e ainda dispor de um editor de páginas no modelo wiki, o Trac se torna mais que uma grande ferramenta, se torna essencial. Forte essa frase, né? Mas espero que concordem comigo ao final.
Passamos a usar o Trac aqui na Riopro copiando de gente que faz as coisas direito. Ou seja, estamos falando do pessoal do Ruby on Rails. Na sua página voltada para a comunidade, eles já falam que usam o “wonderful Trac” para gerenciar o desenvolvimento das futuras versões do framework. E tem dado certo.
Chega de puxar o saco, vamos à prática. Inicialmente, usamos o Trac para o projeto do VoteBolsa. Mas já estavamos quase nos finalmente, então ele ajudou e tem ajudado mais no bug tracking e na ordem de prioridade para as próximas features (e serão várias). Um dos grandes benefícios é deixar bem claro quem está desenvolvendo, através do assign de cada ticket a um usuário (ou mais resumido, um usuário tornar-se responsável). O menu é simples e direto (como se pode ver na imagem abaixo).
Ao entrar na página inicial do Trac do projeto, você é direcionado para o wiki do projeto. Ali, como em qualquer wiki, a criação de páginas e a edição de textos é fácil e rápida, e pode ajudar a documentar objetivos principais e coisas extra projeto, como reuniões realizadas, endereço de servidores, informações importantes, notícias, entre outros.
Em seguida temos o item que considero o mais importante: o Timeline. Aqui pode-se ver em um único lugar, todas as alterações em Tickets (como criação, encerramento, comentários e alterações), como as alterações realizadas no repositório e nas páginas wiki. Ou seja, uma área para se ter uma visão global do projeto. Como opção, você pode desmarcar os itens que não deseja acompanhar (eu, por exemplo, raramente acompanho as alterações de páginas wiki).
O próximo item é o Roadmap. O Roadmap controla o quanto está feito de cada marco esperado do projeto (Milestone). Através de uma interface simples, o usuário pode visualizar rapidamente o percentual percorrido até o momento de cada Milestone. Por padrão, só os marcos que ainda se encontram abertos são mostrados, mas também podemos visualizar todos.
O Trac também permite que você visualize o código fonte do projeto (através de uma interface a seu controle de versões, no menu Browse Source) e possui também a possibilidade de ver os tickets (View Tickets, onde podem ser criados formas personalizadas de consultar os tickets existentes ou já fechados, por exemplo) e criar novos Tickets (New Tickets).
Mas quero me focar no Roadmap. Vendo ser o Trac extremamente funcional, foi óbvia a decisão usa-lo para o nosso novo projeto ultra secreto. E nesse projeto, queriamos ter um controle mais preciso do prazo de duração, menos surpresas no final e mais agilidade no desenvolvimento. Por isso, adotamos alguns dos princípios do Manifesto for Agile Software. Entre os itens principais, queremos uma interação grande entre os indivíduos que são parte do projeto e que o projeto responda as mudanças de plano que podem ocorrer ao longo do percurso. E aí entra o Trac e o Roadmap.
O que estamos fazendo é criar um Milestone global para a versão 1.0 do novo projeto. Nesse Milestone estão armazenados as perspectivas globais do projeto. Em seguida, criamos Milestones para cada iteração (que deve ser funcional, tem um prazo definido e ser toda coberta por testes).
O próximo passo foi dividir os tickets da Milestone 1.0 entre as Milestones de cada iteração e anotamos nos tickets da Milestone 1.0 a que tickets de cada Milestone menor ele faz parte. Dessa forma é fácil controlar quando a funcionalidade estará totalmente terminada e otimizar o fluxo do projeto. Novas ideias que surgirem são cadastradas nessa Milestone 1.0 e posteriormente alocadas nas iterações pertinentes.
Sei que nada do que foi falado aqui é novidade, o que queremos é passar a informação de como estamos integrando perspectivas diferentes e complementares. Espero que o artigo tenha sido proveitoso.
Links:
- http://en.wikipedia.org/wiki/Issue_tracking_system
- http://trac.edgewall.org/
- http://dev.rubyonrails.org/
- http://www.cvstrac.org/
Eu acho o trac muito bom, mas já que vocês trabalham com o Rails, eu recomendo usar o retrospectiva (http://retrospectiva.org).
Ele é muito parecido com o trac, é feito em rails, suporta a múltiplos projetos, e etc.
E se quiser estudar código rails avançado, estude o código do retrospectiva. É um dos projetos open source rails com o código mais complexo que eu vi.
Marcus