Alisson Vale

Documentação em projetos ágeis sempre foi um assunto muito polêmico. Há ainda muita gente que a considera um mal necessário. Talvez não seja muito difícil definir uma boa estratégia de documentação se houver um pouco de bom senso e criatividade. Como disse Scott Ambler, um projeto ágil persegue dois objetivos. (a) Objetivo primário: Entregar software funcionando (b) Objetivo secundário: Dar sustentabilidade para o próximo esforço.

Documentação tem haver com o objetivo secundário. O fato de ser secundário não o faz ser menos importante. O fato é que cada documento que uma equipe deve gerar tem um custo, e esse custo tem que ser muito bem dimensionado com relação ao benefício que ele causa.

Um dos principais problemas da documentação é ela não estar atualizada. Uma boa abordagem para incentivar sua atualização é mantê-la o mais integrada possível com os outros artefatos que o desenvolvedor ou a área de qualidade trabalham no seu dia-a-dia. Assim será fácil e prazeroso mantê-la atualizada. Um exemplo disso pode ser observado na figura 1 (É melhor clicar na imagem para vê-la melhor). Ela representa um documento executável.

 
Figura 1: Exemplo de um documento executável

Na verdade, trata-se de um documento para execução de testes web com o Selenium, mas ele tem algo mais dentro dele. Há comandos que não são interpretados pelo Selenium, mas por um outro tipo de parser que pode ser utilizado para transformar o documento em um outro artefato; fazendo-o servir para diferentes propósitos, como por exemplo, uma especificação funcional, um caso de uso ou até um manual de usuário. No exemplo da Figura 1, pode-se notar na coluna parâmetro I, que há comandos que serão executados para a criação automatizada de um manual ou de uma especificação (spec) ou de ambas (manual, spec). Diferentes outputs podem ser gerados dependendo de onde o documento será visualizado: pdfs, documentos words, ou ainda podem ser diretamente publicados em portais ou wikis. Veja, na Figura 2, qual seria o resultado desse documento publicado no mediawiki.

 
Figura 2: Visão do documento executável já
transformado em uma página wiki

Repare também que o documento pode ser diretamente mapeado com o sistema de issue tracking. No caso desse exemplo, por meio de uma integração do Mantis com o MediaWiki. O documento pode comportar também links para outros issues relacionados, bem como outros documentos executáveis. Trata-se de uma forma bem interessante de manter os documentos vivos, fazendo parte efetiva do processo de desenvolvimento. 

No início desse mês foi divulgada a pesquisa anual realizada pela VersionOne em conjunto com a APNL (Agile Project Leadership Network) sobre a situação atual do Desenvolvimento Ágil no mundo. Foram mais de 1700 entrevistados em 71 países. Pelo menos 30% dos entrevistados atuam em empresas com mais de 250 funcionários.

A pesquisa não serve para avaliar a penetração dos métodos ágeis no mercado de TI de modo geral, mas dá uma idéia de como as pessoas os têm implementado em suas empresas.

Dois números me chamaram a atenção:

1. O Scrum aparece em aproximadamente 70% dos projetos como metodologia utilizada; ou sozinha, ou associada a alguma outra, como XP por exemplo.
2. 82% dos entrevistados afirmaram usar uma ferramenta de issue tracking em seus projetos. Em termos de ferramenta, é o maior percentual, ganhando de ferramentas de testes e de integração contínua. Isso certamente é reflexo da simplificação no uso de ferramentas que os métodos ágeis propiciam.

Porquê Scrum?

Eu justificaria essa adoção em massa ao Scrum, analisando os seguintes pontos:

• O Scrum é muito simples de entender e é um ótimo primeiro passo para a entrada no mundo Ágil;
• Seu público-alvo é formado por quem tem poder de decisão para influenciar seus projetos (gerentes e líderes)
• É muito bem documentado;
• Não sugere práticas que gerem resistência inicial;
• Não interfere diretamente nas práticas de desenvolvimento já utilizadas pela equipe que o adota;
• E aquilo que eu acho que teve o maior peso: Hoje o Scrum já movimenta um mercado de consultorias, treinamentos, certificações, eventos e papers. E tal mercado vem sendo muito bem administrado pela Scrum Alliance.

Apesar das críticas iniciais ao modelo de certificação utilizado pela Scrum Alliance, minha impressão é que é esse modelo que vem trazendo cada vez mais pessoas e empresas para buscarem conhecimento e treinamento sobre o assunto. Hoje as empresas não costumam apostar seu futuro em algo que não seja apoiado por algum tipo de empresa ou instituição atuante.

Talvez seja uma boa lição para outras metodologias e para a própria Agile Alliance. Apesar de haver a necessidade legítima de se manter a natureza "open-source" do movimento, é importante que alguma instituição sem fins lucrativos possa servir de referência comercial para o mercado em geral.

O DSDM tem um modelo semelhante, mas o seu Consortium bem estruturado não foi capaz de vencer uma maior complexidade conceitual da metodologia e sua atuação mais contundente em alguns países europeus.   

É um tema polêmico, eu sei. Mas se deu certo para o Scrum, porque não daria para as outras metodologias?