BT

Documentação Ágil: Há clareza?

por Amr Elssamadisy , traduzido por Herbertt Bamonde em 31 Mar 2010 |

"Software em funcionamento mais que documentação abrangente.", Manifesto Ágil, 2001.

Documentação Ágil não é exatamente o assunto mais fácil de se abordar na comunidade. Quanto de documentação devo criar? O que funciona? O que não funciona? Como partir de um processo tradicional para um processo ágil com relação aos documentos? Esta é uma área que carece de explicação na comunidade.

Um post recente no blog Zen Agile fez a seguinte pergunta "Quanta documentação é  necessária?". O escritor falou sobre sua experiência com as agências governamentais e os motivos por trás dos grandes documentos de processos:

Foi sugerido que, toda essa documentação é necessária "pois somos do governo". Pesquisando mais encontrei as verdadeiras razões para isso:
  1. O negócio precisa de informações consistentes para aprovar os builds
  2. Os desenvolvedores precisam saber o que o sistema foi projetado para fazer
  3. Outros desenvolvedores precisam saber como o sistema foi construído para fazer melhorias
  4. Outros desenvolvedores precisam saber como o sistema foi construído para fazer manutenções
  5. O governo requer de informações suficientes em ordem para saber porque o dinheiro foi gasto e como foi gasto
Na minha experiência, no entanto, poucas pessoas entendem a documentação de requisitos de negócios. Eles tendem a ler o plano do projeto para ter certeza do estado atual e lógico e se é está indo conforme eles planejaram, eles também usam o mapa dos processos para ter uma melhor noção, pois gráficos tendem a ser mais intuitivos do que casos de uso. Mas no geral, conseguindo assinar e aprovar algo que eles não tenham visto é meio ... bem ... não é lógico.

O blog, então, vai para um relatório alternativo da documentação que consiste em:

  1. Articular o contexto via personagens, cenários e diagramas de contexto,
  2. descrever o requisitos com mapas de processos, e matrizes de rastreabilidade,
  3. documentar a solução com modelo de dados, site maps, navegação, e desenho da UI,
  4. validar a solução via protótipos, assinaturas acontecem aqui, de forma iterativa, e
  5. documentar o build do sistema o qual inclui código, testes, e modelo físico de dados.

Este processo acima tem foi criado a partir da experiência. Mas será que temos alguma coisa parecida hoje na comunidade?

Hoje temos as estórias, casos de uso, e testes como especificação. Mas isso é tudo que temos? Existe um livro sobre Documentação Ágil que menciona nunca ter ouvido falar até pesquisar esse tema. Existe um capítulo em um livro sobre documentos representacionais e evocativos. E existe até um artigo na InfoQ escrito a 3 anos átras sobre o assunto.

Será que nós temos um consenso quando se trata de documentação? É realmente difícil falar porque pouco é escrito sobre o assunto. Talvez o assunto seja tão simples para escrever sobre. Ou talvez seja tão complexo e nós realmente não temos uma boa idéia para recomendar.

E você leitor tem alguma boa idéia? Por que será que tão pouco é escrito sobre o assunto?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT