InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

Dois Tipos de Documentos Ágeis - Nem a Mais, Nem a Menos!

Postado por Vikas Hazrati , traduzido por Marcelo Andrade em 14 Ago 2009

Seções
Processos e Práticas
Tópicos
Agile nas empresas ,
Agile ,
Técnicas Ágeis
Tags
Documentação

O Manifesto Ágil recomenda ter-se “Software funcionando mais que documentação abrangente". Isto tem levado muitas equipes a acreditar que não existe necessidade de documentação em projetos ágeis. Os críticos apontam a limitada documentação como uma das fraquezas das metodologias ágeis. Ron Jeffries destacou que as metodologias ágeis não recomendam que não haja nenhuma (nem pouca) documentação, mas sim que enfatizam fortemente que haja a documentação certa. Ele menciona,

Um dos argumentos contrários à XP sequer é verdadeiro. As pessoas acham que dissemos que documentação é uma má ideia. O XP é focado no diálogo direto como meio para máxima efetividade. Nossas recomendações sobre documentação seguem este simples fato.

Com outras palavras, Eelco Gravendeel acrescenta que há apenas dois tipos de documentação em metodologias ágeis,

  • Documentos necessários para que todos os integrantes da equipe trabalhem no projeto – Em um mundo ideal, os membros da equipe estão colocalizados e todo o conhecimento deveria ser compartilhado e transferido por comunicação direta. Entretanto, se a equipe estiver distribuída e o conhecimento precisar ser transferido, então escrever documentos e suplementá-los com conferências de áudio/vídeo pode ser útil. Um conjunto mínimo de documentos também é necessário para que as equipes possam falar uma linguagem ubíqua e estejam num mesmo patamar de entendimento.

Eelco sugere que muitos documentos, que são criados para apoiar a criação do produto, demandam uma atenção bem próxima, uma vez que tais documentos perdem-se tão logo o projeto esteja concluído. Segundo ele,

Tão logo você aceite que os documentos que são escrito apenas para apoiar o processo de criação do produto devem ser perdidos assim que o projeto esteja terminado e o produto entregue, há a esperança de que você também possa resistir à vontade de deixar qualquer documento totalmente pronto e 100% correto! Isto é exatamente a razão que faz da escrita de documentos uma tarefa que consome tanto tempo (e portanto, uma tarefa tão custosa!). Uma vez que você aceite que você só precisa de fato escrever apenas o suficiente para transmitir sua mensagem ou para evitar de esquecer coisas importantes, você vai compreender que papel & caneta, fotos de desenhos em quadros brancos, rabiscos no verso de diagramas, cartões de histórias, etc., são o bastante para estes propósitos!
  • Documentação a ser entregue junto com o produto final. - Estes são os documentos que fazem parte do produto entregue e que são acordados em conjunto com o cliente. Exemplos típicos incluem

  1. Manuais de usuário
  2. Manuais de desenvolvedor
  3. Guias de manutenção (para como operacionalizar o software)
  4. Documentação técnica (para manter o código-base) etc.

Mesmo no caso destes documentos, Eelco sugere,

Quando você acordar sobre as documentações que serão entregues junto com o produto, você ainda pode ser criativo quanto ao formato da documentação. Você pode escrever extensos manuais de usuário, ou você pode usar técnicas modernas como manuais em vídeo gravados com screencast. Esta segunda opção costuma ser mais barata (estatisticamente, cerca de 10 vezes mais barata!) e com muito mais possibilidade de ser utilizada de fato.

Assim, tem-se que há dois tipos de documentos, um que auxilia à equipe e outros que precisam ser entregues junto com o produto final. Se uma equipe ágil estiver preparando documentos que não se encaixem numa dessas categorias, então tais documentos vão demandar um cuidado especial. Em muitos casos, a equipe deveria ser capaz de evitar ter de criar tais documentos.

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.