IGTI Blog
desenvolvimento ágil

Como lidar com a documentação em projetos ágeis?

Um mal-entendido comum quando se fala em métodos ágeis é com relação à documentação de projeto e de produto.

Afinal, quando o manifesto ágil afirma que software em funcionamento é mais importante que uma documentação abrangente, o que exatamente ele quer dizer? Que não é mais necessário documentar? Que métodos ágeis são contra documentação?

De fato, nos métodos ágeis a documentação é tratada com menos prioridade que nas abordagens tradicionais. Mas isso não quer dizer que eles sejam contra documentação, nem que os produtos desenvolvidos em projetos ágeis não sejam documentados. O que ocorre, isso sim, é que os métodos ágeis encaram a documentação com uma abordagem diferente.

Neste post, resumiremos essas diferenças em três pontos.

1) O desenvolvimento ágil reduz a necessidade de documentação

Existe mesmo uma tendência natural em se documentar menos quando se usa um método ágil, já que a abordagem ágil valoriza a comunicação direta, cara a cara, não só entre os desenvolvedores mas também com o cliente e usuários. E os métodos ágeis criam todo um contexto para que isso seja possível:

  • Times com tamanho limitado, o que facilita a comunicação informal;
  • Contato direto do time com aqueles que definem requisitos e prioridades (materializado na figura do Product Owner do Scrum ou no envolvimento do cliente real, no XP), reduzindo assim a necessidade de documentação para se definir e transmitir o que precisa ser desenvolvido;
  • Práticas de código limpo, TDD e arquitetura simples, o que torna o código mais legível e auto documentado.

Mas, claro, tudo isso não necessariamente elimina a necessidade de se produzir documentos. Chegamos, então ao segundo ponto.

2) Métodos ágeis não são contra documentação, desde que ela gere valor

Uma mudança que a abordagem ágil trouxe em relação à forma de pensar a documentação, foi parar de gerar documentos simplesmente por gerá-los, por estarem previstos em algum processo. Ao invés de documentar tudo como padrão, passamos a questionar o valor real de cada documento. Se um documento é necessário para cumprir um requisito regulatório importante, isso é um tipo de valor. Se o produto tem regras de negócio complexas que o cliente acha importante ter por escrito para referência futura ou para divulgar aos usuários, isso é um tipo de valor. Se o desenvolvimento é feito para um cliente que exige contratualmente a geração de documentos A, B e C (algo muito comum em licitações para o governo), isso também é valor.

Quando esse valor superar o custo de documentar, podemos e devemos fazê-lo. Mas é bom lembrar que o custo aqui envolve tanto o custo de criar o documento como o de mantê-lo atualizado depois. E aqui, também, os métodos ágeis trazem uma diferença em relação às abordagens prescritivas tradicionais: o momento em que a documentação é gerada é escolhido de forma a reduzir o custo de manutenção. Chegamos ao terceiro ponto.

3) A documentação gerada é tratada como um resultado, e não como um insumo

Nas abordagens tradicionais é comum documentar para definir o que será desenvolvido, antes de desenvolver como, especificações de requisito, casos de uso detalhados, modelos de projeto. Esses documentos precisam ser mantidos atualizados até o fim do projeto, quando são então entregues como artefatos do produto. Notem que, nessa abordagem, estamos documentando as coisas enquanto elas ainda estão sendo definidas. E esse pode ser o pior momento para documentá-las, porque ainda estão muito instáveis. Isso significa que, mesmo que o custo para criar a documentação seja baixo, o custo para mantê-la atualizada pode ficar muito alto.

Na abordagem ágil, como reduzimos a necessidade de documentar antecipadamente para comunicar o que precisa ser desenvolvido, podemos concentrar a documentação naquilo que tenha real valor e deixar para fazer isso no momento mais oportuno — que pode ser durante ou mesmo após o desenvolvimento daquela funcionalidade, quando as coisas já estão mais estáveis. Reduzimos, assim, o custo de manter a documentação atualizada.

Na prática, o momento de tratar cada tipo de documentação num projeto ágil pode ser materializado de duas maneiras:

  • Incremental: Para a parte da documentação que for importante gerar durante o desenvolvimento, de maneira incremental, isso pode ser feito adicionando um critério na definição de feito (Definition of done) do projeto. Assim, garantimos que nenhum item será considerado aceito se a documentação não tiver sido produzida.
  • Como item de backlog: Para a parte da documentação em que for mais interessante gerar de uma única vez para o produto, podemos tratá-la como itens de backlog. Assim, o Product Owner analisará qual a prioridade desse item em relação aos demais itens de backlog do produto, e decidirá o melhor momento para passar esse item ao time para desenvolvimento.

Seja incremental ou como item de backlog, notem que estamos tratando a documentação como um resultado do desenvolvimento (documentamos o que foi feito), e não como um insumo (documentar para discutir e transmitir o que será feito).

Simples, não?

Para saber mais sobre esse tema, recomendamos que assista a este vídeo. Ele foi criado como material complementar para a disciplina Métodos Ágeis em Engenharia de Software, que faz parte do MBA em Engenharia de Software com Métodos Ágeis do IGTI.

Professor autor: Eduardo Pereira Borges