Nessa terça-feira fizemos a nossa primeira retrospectiva com o time do Dojo Online (projeto open-source que estamos desenvolvendo na Universidade de São Paulo). Após esse primeiro mês de interação, resolvemos nos reunir para refletir sobre o andamento do projeto. A reunião aconteceu em uma sala com post-its coloridos e canetas.

Na primeira parte da retrospectiva, a idéia era colocarmos nossas respostas em post-its para três perguntas:

• O que foi bom? O que fizemos bem?
• O que podemos melhorar?
• O que atrapalhou? O que foi ruim? O que não queremos mais?

Havíamos combinado antes que não haveria nenhum tipo de ataque pessoal (nada de respostas do tipo ‘fulano não faz nada’), e que ninguém precisaria identificar-se como autor da resposta. Gastamos então aproximadamente 15 a 20 minutos preenchendo nossos post-its e colando-os na lousa.

A segunda parte e mais interessante da retrospectiva foi a discussão dos problemas. Começamos primeiro pela terceira pergunta: O que nos atrapalhou? A maioria das respostas se encaixou em problemas com o ambiente (falta de café, máquinas lentas, falta de plugins no Eclipse), problemas com testes de interface (realmente não conseguimos até agora executar um teste automatizado de interface no GWT), falta de experiência do time com métodos ágeis (realmente, esse é o primeiro contato da maioria com XP). A única coisa um pouco mais pessoal que rolou foi um ‘pessoas atrasadas nas reuniões gera a necessidade de rediscutir os assuntos’. Eu anotei que senti ‘pouca comunicação com os clientes durante a interação’. Alguns outros problemas como ‘retrabalho por falta de comunicação’ também foram levantados.

Já na segunda pergunta, levantamos que deveríamos ‘melhorar nossas estimativas das histórias’ (estimamos muito mal essas histórias, algumas muito longe do que foi a realidade), ‘mais estudos fora do horário’, ‘comunicação da equipe’, ‘participação maior do time na lista de discussão’, ‘procurar atender melhor as necessidades do cliente’, ‘tarefas acopladas’ e uma muito interessante: ‘validação de histórias concluídas’ (tivemos muitas histórias marcadas como concluídas, mas na verdade, elas precisavam de mais alguns ajustes). Vimos também que deveríamos melhorar no desenho do fluxo de telas do projeto, pois não tínhamos nenhum rascunho e isso estava criando muitas dificuldades para o time (muitos post-its sobre isso!). Houveram sugestões também para refatoração de código, pois alguns membros estavam achando o código muito complicado.

Já para a primeira pergunta (parece ser a mais fácil de responder, mas não é!), a maioria das respostas foram sobre a união e humor da equipe. Algum dos integrantes, provavelmente membro de algum grupo esotérico, escreveu ‘energia do pessoal’ ! Realmente, o time está muito integrado, se ajudando o tempo todo na resolução dos diversos problemas que surgiram durante a interação. Muitos gostaram também de programar pareado, já que a produtividade e qualidade do código cresce muito! Outro detalhe interessante é que houveram muitas respostas do tipo ‘tracking realmente ajuda a ver o andamento do projeto’. Durante toda a interação, tratamos de manter todos os indicadores atualizados, e com isso, tínhamos a visão exata do estado do projeto naquele momento.

Após uma rápida leitura de todos os post-its, resolvemos agrupá-los por categorias, para então acharmos soluções para nossos problemas:

• Sobre os testes de interface, decidimos que não iríamos fazer testes de interface por enquanto, e que nos concentraríamos nos testes da camada de domínio. Para os diversos problemas levantados, foi sugerida a criação de um quadro de dúvidas, e que ao final do dia, iríamos resolvê-las todas com o cliente. Decidimos também que nossas reuniões diárias serão feitas em horários pré-determinados (antes não tínhamos horário fixo!), e que todos devem participar mais das questões levantadas na lista de discussão via e-mail. Sugerimos também o “sino da atenção”, para que quando algum membro do time precisar se comunicar com todos, este deve conseguir chamar a atenção de todos de uma só vez, para não ter que ficar repetindo a mesma informação.
• Combinamos também que tentaríamos refatorar os códigos que estavam por demais complicados. Sobre os problemas de falta de atenção com a interface, decidimos também trabalhar em um rascunho de fluxo das telas, para que todos tenham pelo menos uma visão básica das telas do projeto. Esses mesmos rascunhos serão validados com o cliente antes de serem implementados efetivamente. Sobre as estimativas, acreditamos que nessa segunda interação elas serão melhores. Sobre o problemadas tarefas acopladas, decidimos que vamos trabalhar mais juntos no momento de quebras as histórias em tarefas.
• A parte boa, não há muito o que comentar! Vamos tentar continuar assim, por enquanto não houveram feridos no time!

Fazendo uma análise geral da retrospectiva, vimos que nosso grande problema foi a COMUNICAÇÃO, pois olhando para as ações que definimos, a maioria delas tenta resolver problemas relacionados a comunicação! Ficamos surpresos ao perceber isso! Como já dizia o manifesto ágil, “Individuals and interactions over processes and tools”. E realmente, eles estavam certos!

Criamos um quadro na nossa sala, com as principais ações definidas na retrospectiva, e agora vamos atrás delas!

Tiramos algumas fotos da retrospectiva, que você pode ver aqui, aqui, aqui e aqui.
Curioso com os indicadores? Veja eles aqui, aqui, aqui, aqui, aqui, aqui e aqui.