Gestão de projetos com Trajectory

Posted by Daniel Lopes on 14/05/2011

Trajectory

Nos últimos 3 anos tenho sido usuário assíduo do Basecamp da 37Signals. Um excelente gerenciador de projetos, simples, elegante, coerente e o mais importante: perfeito para comunicação.

Ponto forte do Basecamp, na minha opinião, é a comunicação aliado a simplicidade. Isso permite que pessoas não técnicas possam contribuir e se comunicar de forma bastante efetiva e ainda acompanhar o estado do projeto.

O problema

No entanto Basecamp não foi feito pensando em desenvolvimento de software e nós utilizamos várias práticas que nos forçaram a criar “regrinhas” dentro do sistema.

Como nós somos adeptos de XP e outras práticas ágeis precisávamos de um fluxo que acabava não sendo perfeito no Basecamp. Por exemplo, planejávamos o desenvolvimento com quatro listas de tarefas (Backlog, Em Andamento, Review e Produção) e a cada iteração as tarefas passavam nessas quatro listas.

O problema que essa organização acabava inibindo o cliente de fazer de se comunicar (o coisa mais importante no desenvolvimento). Cliente ficava com receio de criar as próprias tarefas, re-ordenar por prioridade e aceitar as funcionalidades na etapa de review. Ou seja, apesar de funcionar para nós, não funcionava bem para o cliente pois era um fluxo complexo.

Depois de tentar essa simulação de um Kanban no Basecamp nós acabamos passando para o Pivotal. No entanto, a interface do Pivotal é ainda mais inibidora que o nosso modelo de “Kanban” no Basecamp. No final, com Pivotal, o cliente também não interagia com as requisitos, não dava feedbacks e ainda perdemos a parte de mensagens integrado que o Basecamp faz muito bem.

A solução

Para nós é imprescindível ter um bom gerenciador pois trabalhamos remotamente. Já estávamos desgastados com as tentativas anteriores até que a ThoughtBots lançou o Trajectory.

Ao passarem pelo mesmo problema com seus clientes, a empresa resolveu desenvolver seu próprio gerenciador de projetos de software e já integrado com várias das práticas ágeis que são importantes para planejamento, comunicação e acompanhamento.

Neste post eles descrevem as razões que os levaram a desenvolver um novo gerenciador. Antes que pensem alguma coisa, eu não estou recebendo nada para escrever este post mas penso que ferramentas/serviços bons devem ser divulgados :).

Trajectory junta os conceitos de um backlog que pode ser organizado em iterações e priorizado da melhor forma. O ponto forte do sistema é que além de já ter o modelo de histórias/backlog pronto para o que precisamos ele já calcula a velocidade da equipe com base no histórico, o progresso da iteração e já divide as próximas iterações baseado nisto (semelhante ao Pivotal, mas de uma forma mais amigável).

Outro grande benefício é sua capacidade de comunicação. Da mesma forma que o Basecamp, o sistema possui uma área separada para mensagens (onde também são aceitos anexos) e após a discussão é possível transformar a mensagem em uma história. Cada história possui uma tela própria para continuar as discussões e comentários e também atribuir quais as tarefas são necessárias naquela funcionalidade (design e/ou desenvolvimento).

Trajectory

Além deste modelo de discussão focado em funcionalidades, cada história também possui estágios (start, stop, deliver e accept) onde é possível fazer uma retrospectiva adicionando um comentário ao entregá-las.

O sistema também possui uma forma de criar milestones e isso foi uma feature fundamental que ainda vou explicar o motivo.

Trocando em outras palavras, o sistema é junta a melhor parte do Basecamp (comunicação) com a melhor parte do Pivotal (planejamento ágil) em uma interface amigável para usuários não técnicos.

O maior benefício

Com o Trajectory nós conseguimos o maior benefício que estávamos perseguindo e que é tão complexo de atingir em desenvolvimento remoto. Comunicação ativa entre nossa equipe e o cliente.

A comunicação flui muito bem tanto em discussões isoladas para conseguirmos pensar nas histórias, quanto durante as iterações onde o cliente cria novas tarefas, prioriza, aceita e rejeita as histórias, comenta e acompanha tudo de uma forma muito ativa.

Outro fator que foi muito importante foram os milestones. No Basecamp, nunca conseguimos tirar reais proveitos dos milestones mas por causa do design do Trajectory o impacto de um milestone no sistema é muito maior. Com uma barra dourada na mesma lista de tarefas das iterações fica bem claro qual a distância que estamos para atingir aquele milestone. Essa barra tem um fator psicológico interessante pois coloca tanto a equipe de desenvolvimento quanto o cliente em um esforço contínuo para atingir aquele objetivo próximo.

Trajectory

Bugs e ausência de funcionalidades

Mas nem tudo são flores, quando começamos a usar o sistema esbarramos em alguns bugs. No entanto, esses bugs nos fizeram confiar mais ainda no serviço pois a resposta e solução foram extremamente rápidas.

Também é bem claro que o sistema esta em sua fase inicial e que faltam ainda várias features. Faltam coisas como a capacidade de escolher quem irá receber as mensagens, melhorias nas telas de configurações, melhores ferramentas para a leitura do histórico, um controle do início e fim da iteração entre outras coisas mais.

Conclusão

Apesar dos bugs e a falta de alguns recursos de forma alguma essas coisas afetam os benefícios do sistema. Então minha conclusão é que apesar de ser um sistema muito novo o Trajectory já conseguiu resolver um dos maiores problemas que tínhamos que era planejamento eficaz e comunicação ativa.

Quanto ao custo do sistema o valor é muito razoável para os benefíci