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?

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.