AgileFAQ #1: E a documentação?

Quando fazemos apresentações sobre ágil ouvimos muitas vezes as mesmas velhas perguntas. Confesso que às vezes acho um pouco … digamos… chato responder a essas perguntas pela vigésima vez (#prontofalei). Mas, cá pra nós, não dá pra negar que essas perguntas são chave para o entendimento da filosofia ágil.

Por isso resolvi iniciar incitar essa série de posts aqui na visão ágil, com o intuito de que tenhamos uma muleta prática em que nos apoiar toda vez que precisarmos responder (ou evitar 😉 ) essas perguntas.

De minha parte, acho que a pergunta mais frequente de todas, campeã indiscutível, é a velha “e a documentação?”. Então resolvi começar a séria com ela.

 

 Já tive várias respostas para essa pergunta. A primeira que me vem à mente hoje em dia é: mas quem foi afinal que falou pra essa gente que nós não documentamos nada?!  Esse é na verdade apenas mais um preconceito bobo cultivado pelo telefone sem fio de pessoas que ouvem cantar o galo mas não sabem onde.

Talvez seja por que o manifesto proclama que “software funcionando vale mais que documentação compreensível”. Quando essas frases ecoam por aí parece que o diz-que-me-disse das pessoas acaba esquecendo de levar junto a frase final do manifesto. (Não vou copiá-la aqui. Vai lá e lê!).

Não é que agilistas não gostem de documentação. Parem com isso! O que não gostamos é do mal hábito que se cultivou em basear absolutamente tudo em documentação formal. Trata-se de uma cultura que se desenvolveu por várias razões em nossa indústria nas últimas décadas, mas que simplesmente não faz mas sentido.

Bem, pra falar a verdade, verdade mesmo, XP realmente diz que a melhor documentação que existe sobre o código fonte é o próprio código fonte. Mas isso de forma alguma deve ser interpretado como “se você escreve documentos, então você não faz XP”. Melhor seria entende-la como “trabalhe no sentido de criar código auto explicativo que dependa cada vez menos de artefatos não integrados ao código”.

A maioria das comunicações que nos acostumamos a fazer com documentos formais seriam muito mais eficientes se feitas pessoalmente, conversando, ou até mesmo por telefone. Documentos formais são caros e chatos de manter atualizados. São raras as situações em que são realmente necessários.

Uma das melhores respostas que já ouvi para a pergunta foi dada pelo Juan Bernabó, em um podcast publicado pela ImproveIT (não me pergunte qual), onde alguém perguntou algo como “mas que documentação vocês fazem em Scrum?” A resposta, de tão curta e direta, não chegou nem a ser entendida de primeira por quem perguntou: “a necessária”.

É isso. Se uma documentação é necessária, faz-se a documentação e pronto. Seja lá pelo motivo que for. Não é raro, por exemplo, encontrar clientes que simplesmente não dão o braço a torcer e querem porque querem a documentação dos casos de uso antes que se comece a desenvolver. O que fazer? 

Ora, faça as documentações! Que mal há nisso? Crie cartões ou post-it’s para “escrever a documentação do caso de uso CadastrarUsuário”, estime seu esforço e o coloque no backlog, para ser priorizado. Se seu cliente priorizar a documentação, assim será. O mais provável é que ele se convença, com uma ou duas iterações, de que ele na verdade não precisa daquilo… Mas é assim mesmo. Algumas vezes o caminho mais rápido é o mais comprido e tortuoso.

Acho que a lenda que diz que “ágil não documenta nada” poderia ser corrigida para “ágil recomenda que se reflita a respeito de quais documentações são realmente necessárias”.

Tenho certeza de que ainda existem muitas outras respostas para essa pergunta infame que tanto confunde as pessoas. O que deixei aqui foi apenas um ponto de partida para alguma reflexão e uma pequena provocação para que os colegas complementem com seus pontos de vista.

 

Sobre o Autor:

Bruno Pedroso

 

Bruno Pedroso é Bacharel em Ciência da Computação pela UnB, onde atualmente desenvolve seu projeto de mestrado em engenharia de software. Desenvolvedor com mais de 10 anos de experiência, atua hoje como coach de projetos e coordenador da área técnica da SEA tecnologia, dando grande enfoque à aplicação de valores e princípios XP.