Documentação no mundo ágil, usar ou não usar?

Documentação no mundo ágil, usar ou não usar?

Sempre que estamos em uma consultoria para empresas de TI, em treinamentos e até mesmo no dia a dia, acabam perguntando como o Agile trata a parte de documentação de software. Por mais trivial que possa ser essa pergunta, muitas vezes ela passa por uma série de discussões filosóficas, mas vou tentar aqui trazer uma luz sobre este tema.

Para começarmos a falar do assunto, precisamos voltar um pouco no tempo e relembrar alguns detalhes que motivaram a criação da “Documentação de Software”. Quando foi criada a engenharia de software por volta dos anos 60, viu-se a necessidade de algo que comunica-se a todos os envolvidos de um projeto de software o que precisava ser feito, visto que, entre o cliente, a necessidade do cliente e o que era entregue pra ele, muitas vezes existiam vários abismos, foi então que nasceu a Engenharia de Requisitos, que tinha como papel principal, fazer a ponte entre as necessidades de negócio e a visão técnica do projeto.

No início existiam pouquíssimos padrões, até porque as possibilidades técnicas da época eram inferiores a placas como Arduíno e Raspberry. Porém conforme o tempo foi passando, às possibilidades aumentaram e a complexidade dos sistemas em desenvolvimento também. Havia dependência entre sistemas, a disponibilização de sistemas via WEB e depois de não muito tempo, IOT, Mobile e demais tecnologias atuais. Foi então necessário fazer uma padronização genérica o suficiente para todos entendessem, mas também, especifica para não houvessem dúvidas do que seria produzido e é aí que começaram os sérios problemas. Imagine a documentação necessária para se construir o Word 2003 (veja que estou falando só do Word e de uma versão bem mais simplificada), se formos levar em consideração o padrão mais utilizado da época, ou seja, UML 1.0, seria uma série quase infinita de documentação, visto que para época, revolucionou a forma de produzirmos textos nos computadores, com várias formas de formação, espaçamento e a melhor parte, o WordArt que mudou completamente as capas de trabalhos escolares.

Agora que já relembramos um pouquinho deste passado, vamos para o presente. Quando falamos de agilidade uma das primeiras coisas que temos que ter em mente é o manifesto ágil e falando especificamente de documentação, temos um ponto bem claro: “Software em funcionamento mais que documentação abrangente”. Agora você deve estar pensando: “Hummm, então acho que isso mata toda a documentação né?!”, daí eu respondo com um alto e claro “NÃO!”. “Herege, queime-o na fogueira!”, talvez este tenha sido o pensamento de um agilista que esteja lendo este post, mas volta lá na frase e preste atenção no item em negrito, no próprio manifesto está escrito “mais que”, ou seja, é preferível entregar o software em funcionamento do que fazer uma documentação robusta, mas isso não quer dizer que não pode ser feita nenhuma documentação.

Daí muitos dirão: “Ah, mas a estória de usuário é a documentação do sistema”, então (pausa dramática), não…

Um estória de usuário serve para informar a todos quais são as necessidades negociais e não o COMO o software precisa ou foi feito.

Agora que eu dei um nó na cabeça, vou deixar aqui o meu ponto de vista do caso. A primeira coisa para saber se é necessário ou não fazer documentação, e ainda, qual a documentação necessária, é parar para pensar, “O que agrega valor para o meu cliente?”, porque desta pergunta, imagine o seguinte cenário: você está desenvolvendo um software para um importante órgão do serviço público, onde vários outros sistemas farão integração com ele, acredito que no mínimo faça sentido haver um documentação onde explique as formas de serem realizadas estas integrações correto?! Mas o grande pulo do gato é, que tipo de documentação você utilizará… Veja, se você pensar na UML pura, será uma infinidade de documentos a serem preenchidos, que talvez nem façam sentido para quem está se integrando, mas uma Wiki neste caso, além de simplificar, pode atender plenamente à necessidade de tornar pública a forma de integração.

Se você ainda está aqui vou dar três dicas de ouro para avaliar o que vale a pena ser documentado:

  1. Entenda o contexto em que você está desenvolvendo, fazer um software interno da empresa exigirá muito menos documentação que para um órgão do governo, não porque no governo as coisas são burocráticas, mas sim porque de uma forma geral (pela minha experiência), o governo terá muitas interdependências internas e externas do que uma organização estritamente particular;
  2. Desapegue-se daquilo que você aprendeu como padrão de documentação de software e pense fora da caixinha. Aqui a ideia é simplificar ao máximo, se algo pode ser uma Wiki ao invés de um documento de caso de uso, então faça somente a Wiki, agora se é necessário um documento de arquitetura mais pesado e detalhado, então faça sem medo, o importante é dar o remédio certo para a doença certa e não sair dando benzetacil (se você não sabe o que é isso, pergunte para o seu pai… rsrsrs), para todo mundo;
  3. Se você tem a possibilidade de não entregar nenhuma documentação, por favor, não invente de fazer a documentação, o software deveria ser necessário para responder a todas as questões, pena que nem sempre é possível.

Enfim, espero que tenha contribuído com a questão e qualquer dúvida, questionamento ou mesmo correção, deixa aqui o seu comentário para enriquecermos ainda mais essa discussão que está longe de acabar…

Share this post

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *