Por definição, documentação é o ato ou processo de documentar, ou seja, reunir informações para provar algo. No contexto de desenvolvimento de software, especificamente em ágil, precisamos documentar o sistema de uma forma que seja também ágil. Para isso, usamos o processo de documentação viva. Vamos entender um pouco mais esse conceito?

Uma documentação é viva porque é dinâmica e acompanha o processo de desenvolvimento desde o levantamento de requisitos e de cenários funcionais até a implementação, gerando documentos e sendo utilizada e conhecida por toda a equipe de desenvolvimento, além dos stakeholders. A “vida” da documentação está relacionada a algo que tem suas “funções vitais” ativas, como por exemplo nortear a implementação de features, revelar o status do sistema ou esclarecer interessados sobre como o sistema funciona. Quem dá vida a essa documentação é a equipe de desenvolvimento, testers e demais stakeholders. Não é um monte de papel engavetado, consultado em casos emergenciais e apenas isso. Pelo contrário, é algo que cresce, muda e evolui junto com o desenvolvimento do sistema, com o envolvimento de toda a equipe e interessados.

Parte da documentação viva engloba a especificação das funcionalidades a partir de exemplos, o que chamamos de especificação por exemplo. Com ela, os interessados não-técnicos podem interagir e entender sem dificuldades, uma vez que a especificação é feita em linguagem natural e é voltada para as regras de negócio. Essas especificações descrevem por meio de exemplos os cenários funcionais do sistema, os quais são “traduzidos” em uma validação que verificará periodicamente (isso é configurável) se o sistema faz o que deveria, ou seja, o que está especificado. Além disso, a validação também avalia se essa especificação continua representando com fidelidade o que o sistema faz, ou seja, se está atualizada. Uma especificação traduzida em validação é uma especificação executável, e isso faz parte do que a constitui “viva”, pois o que é vivo tem reações e interações. A especificação reage contra o sistema que está sendo validado. Reagir às especificações contra o sistema é testar, e os testes também são parte de uma documentação viva.

Um dos artefatos da documentação viva é um documento ou relatório resultante da validação do sistema a partir da especificação executável. Este artefato às vezes pode ser confundido como sendo a própria documentação viva, porém uma documentação viva diz mais sobre o processo que gera esse artefato. O documento ou o relatório final é onde culmina todo o processo de documentação realizado.

O que deveríamos ter em processos ágeis se não uma documentação ágil? Um projeto sem documentação fica refém do entendimento técnico principalmente dos desenvolvedores de software e do que está na cabeça dos que estão trabalhando nele de perto. Uma documentação que não reflete o sistema e que não evolui com ele também não atende às necessidades de processos ágeis, afinal nesses processos nada está escrito em pedra. Uma documentação viva pode ser uma aposta e uma prática de equipes ágeis que se preocupam em garantir a qualidade do que fazem ao invés de apenas “entregar” o que o cliente solicitou no prazo estipulado. A documentação viva pode estar incluída nas estimativas de tempo e esforço de desenvolvimento como uma prática de garantia de qualidade do time.

Um sistema de documentação viva é essencial e deveria ser de alta importância para todos os envolvidos no projeto, principalmente pela equipe de desenvolvimento. É algo que deveria ser comprado por todos do time, que por sua vez deveria se comprometer a dar muita importância a essa documentação quanto se dá ao código fonte do sistema. Por quê? Porque quem vai dizer daqui a alguns meses o que o sistema faz ou não faz para um stakeholder? Quem vai poder orientar as decisões sobre as mudanças funcionais, seus impactos e estrutura funcional do sistema quando este for de grande complexidade? Quem pode mostrar o esqueleto funcional do sistema sem ter que rodar a aplicação em uma reunião não-técnica? Quem pode mostrar ao time como está o sistema, se funciona como deveria ou tem algo quebrado? Esta função é da documentação do projeto. Mas uma documentação convencional é difícil de manter e de atualizar, demanda muito esforço e não acompanha a evolução do sistema ou suas mudanças. É uma documentação morta, que não cumpre sua finalidade. Por isso a documentação deve ser viva. Viva porque é atual e acompanha o sistema, sendo seu reflexo traduzido em formato não-técnico, ao qual não apenas desenvolvedores ou testers têm acesso e podem entender, mas qualquer interessado no projeto.

Ficou alguma dúvida ou tem algo a dizer sobre o tema? Aproveite os campos abaixo! Até a próxima.