O modelo de trabalho da Toyota, que por si só já converge em vários pontos com a abordagem ágil, parece que funciona de maneira semelhante no que diz respeito à documentação. Quem já teve a oportunidade de estudar um pouco o seu processo de solução de problemas sabe como ele é rico em observação, diagnóstico e análise detalhada das questões que influenciam ou são influenciadas por um determinado problema. Mesmo assim, quem espera que a Toyota registre cada passo desse tipo de análise, gerando um grosso relatório a ser utilizado para avalisar as decisões, pode se preparar para rever seus conceitos. Pelo menos é o que diz o best-seller O Modelo Toyota, escrito por Jeffrey Liker e David Meier. Esse livro, que, na minha opinião, deveria estar na cabeceira de todos aqueles que estudam e/ou aplicam o modelo ágil em seus projetos de software, tem um grande número de ensinamentos dos senseis da Toyota que, ou corroboram com as idéias do movimento ágil, ou o expandem em direções inusitadas.

  Figura 1: Esboço de relatório A3 adaptado ao contexto ágil

A técnica possibilita a criação de um relatório capaz não só de documentar as análises e decisões tomadas em um projeto, mas também amplia a capacidade de comunicar seu conteúdo mais eficientemente, além de permitir a colaboração de todo um grupo de pessoas para produzi-lo. O fato de ele estar limitado à parte da frente de uma folha de papel A3 o torna grande o suficiente para conter as informações mais essenciais e pequeno o suficiente para evitar que ele contenha todo aquele detalhamento que afasta o leitor e atrapalha o processo de comunicação. Um relatório desses deve poder contar toda sua história em menos de 5 minutos. Há basicamente quatro tipos de histórias que podem ser contadas por meio de relatórios A3 na Toyota:

Todos eles podem ser facilmente utilizados em um qualquer projeto, Ágil ou não. Mas há dois deles que realmente podem ser muito bem aproveitados no modelo ágil: um relatório que conta a história da solução de um problema e o que conta a história da situação de um projeto. O primeiro pode ser mais um dos instrumentos disponíveis para inpeção e adaptação de projeto ágeis. Na verdade, o relatório é apenas um dos elementos de toda uma metodologia para solução de problemas (eu falo um pouco dessa metodologia em uma série de dois artigos que escrevi para a Revista Visão Ágil sobre aperfeiçoamento de projetos ágeis). Já o segundo tipo de história (aquela que descreve a situação de um projeto), também me chamou a atenção, mas dessa vez por um motivo diferente: talvez esse seja um bom instrumento para contarmos a história de uma iteração para stakeholders ou outros personagens que não participam do seu dia-a-dia e que precisam rapidamente estar informados sobre o seu andamento.

Pensando nisso eu criei um esboço simplório do que poderia ser a história de uma iteração contada por meio de um relatório A3. Uma imagem ampliada desse esboço pode ser obtida clicando aqui.  À partir desse ponto é interessante ler o restante do post com o relatório aberto para facilitar o entendimento.

A primeira coisa que se deve ter em mente ao produzir um relatório desse, é que ele deve contar uma história concisa e sem desvios. Um relatório de situação de projeto (ou relatório de status) é diagramado horizontalmente. A frente da página é dividida em duas partes iguais. O verso normalmente não é utilizado. Dentro dessas duas partes, são criadas 5 seções que receberão o conteúdo do relatório.  O tamanho de cada seção e o seu conteúdo vai depender do enfoque da história que está sendo contada. A primeira seção é o Histórico do Projeto até então. É nesse momento que você situa o leitor descrevendo a exata situação do projeto até o momento imediatamente anterior ao início da iteração. Como estava o projeto antes da iteração começar? Estabeleça o foco em números e utilize gráficos para mostrar tendências. Ao invés de textos com frases corridas, crie enumerações com frases simples. Utilize setas para guiar o leitor pelas informações disponibilizadas.

O  segundo passo é indicar quais foram os objetivos da iteração. Você pode, opcionalmente, contar a história sobre como estes objetivos foram estabelecidos. Um backlog com uma análise de custo-benefício pode servir para este propósito. Nesta seção deve-se ser claro quanto a esses objetivos. Ou seja, ao invés de "Melhorar a cobertura de testes unitários", utilize "Alcançar 85% de cobertura nos testes unitários". Se este for um dos seus objetivos, você deve indicar em que número esta cobertura estava na seção Histórico do Projeto para depois indicar qual foi o resultado alcançado nas seções seguintes. Lembre-se que a história deve ter início, meio e fim. Repare que eu adicionei todo o backlog do projeto ao documento. Pude fazer isso, porque o projeto é pequeno. Em projetos maiores você pode se concentrar em colocar a história da iteração no contexto de um tema ou de uma release. Assim, o escopo ficará reduzido o suficiente para ilustrar seu objetivo mais imediato.

Uma vez esclarecidos os objetivos, podemos entrar nos detalhes de o quê foi implementado para alcançá-los. Aqui vale informar as ações ou os critérios utilizados e quais métricas ou informações foram coletadas de forma que possamos constatar a relação do trabalho realizado com os objetivos estipulados.

Finalmente, as duas seções finais descrevem o resultado alcançado, os problemas e as ações de melhoria propostas. As informações sobre problemas e melhorias propostas podem vir das retrospectivas e devem de alguma forma apresentar elementos que descrevam problemas que ou atrapalharam a execução do trabalho ou o impediram. 

Vamos ver então como a história dessa iteração poderia ser contada em menos de 5 minutos:

"Na parte superior esquerda nós podemos visualizar a síntese de progresso do projeto. Após 4 iterações terem se passado, podemos ver que funcionalidades têm sido desenvolvidas a uma taxa de 8 a 11 pontos por iteração. Até o momento foram desenvolvidos 39 pontos, o que representa 34% do total. A velocidade da equipe, que antes era de 8 pontos por iteração, agora está na média de 9,75, o que indica uma aceleração de 17% quando comparada ao início do projeto. Esse quadro de progresso nos oferece três possibilidades de projeção para o fim do projeto. A projeção mais otimista leva em conta a maior velocidade alcançada até agora, a mais pessimista leva em conta a menor velocidade e uma terceira visão mais realista considera a média de velocidade das últimas 4 iterações. Assim, nosso marco final, no momento anterior ao início dessa iteração, estava previsto para ser alcançado provavelmente entre 7 e 11 semanas.

Ao iniciar a Iteração #5, uma análise de custo-benefício foi feita de forma a selecionar aquelas funcionalidades que teriam maior relevância para implementação imediata. Três histórias foram selecionadas e o comprometimento para o seu desenvolvimento foi estabelecido. Em termos numéricos, apenas mantivemos o índice de entrega alcançado na iteração anterior: 11 SPs.

A implementação das três histórias foi realizada dentro do prazo da iteração. Testes de aceitação, de integração e testes unitários automatizados foram criados para todas elas. Houve uma variação para baixo indesejável no nível de cobertura dos testes unitários, o que deixou a equipe alerta para trabalhar na direção de elevar esse índice novamente na próxima iteração. As variações nas métricas de design não revelaram nenhuma anormalidade.

Com a implementação das três novas histórias, o projeto avançou em mais 10 pontos percentuais chegando aos 44% de completude. As Projeções de término agora estão variando entre 5,2 semanas (cenário mais otimista) e 7,8 semanas (mais pessimista). 

A iteração apresentou um aumento significativo no percentual de tempo alocado em atividades que não geram valor. Esse desperdício que já fora de 17% na iteração anterior, alcançou o patamar de 27% nessa iteração. Um aumento nominal de 10%.  A análise realizada na retrospectiva revelou uma grande quantidade de tempo investida em atividades de instalação e configuração de infra-estrutura de deploy, o que nos fez propor um plano para automatizar essas atividades e, dessa forma, voltar a reduzir esse nível de desperdício para que mais tempo possa ser alocado em atividades que gerem progresso no projeto."

Esse exemplo é totalmente fictício, claro. Mas dá uma idéia do que é ser capaz de apresentar o trabalho de toda uma iteração em menos de 5 minutos, concentrando-se nos pontos essencialmente relevantes para a audiência do relatório. Obviamente, os gráficos, números e métricas podem ser dos mais diversos tipos e podem apresentar as mais diversas informações. O importante é manter o foco no aspecto da comunicação, preocupando-se em ser sucinto e objetivo , sem poluir ou sobrecarregar com dados sem conexão com o que se deseja apresentar.