Lendas urbanas… times ágeis não fazem documentação.

Que fique claro desde o começo da nossa escrita – se você convive com um time que se afirma ágil e não mantém a mínima gestão do conhecimento do seu produto em documentos e vídeos, é bem provável que você seja esteja lidando com um time frágil (que é a antítese de um time ágil). A ausência da documentação é uma das falsas dicotomias sobre o uso de métodos ágeis, que infelizmente é citada com despreparo por muitas pessoas que não compreendem os fundamentos de métodos ágeis. Times ágeis documentam sim, mas o documento não é usado  como elemento prescritivo para disparar a atividade seguinte. Por exemplo, um documento de caso de uso não precisa ser estar pronto para que a implementação de uma funcionalidade esteja pronta. Documentos são muito mais descritivos de uma situação ou estado onde o produto se encontra. Documentos, em métodos ágeis, são construídos de forma contínua ao longo das iterações e o foco central é a gestão do conhecimento. O conceito da documentação AS-BUILT (como foi construído) se torna ainda mais importante do que a documentação prescritiva que ocorre em times tradicionais.

Como isso ocorre na prática? 

1. Um time coeso com um analista de negócio, um desenvolvedor e um analista de testes começa a trabalhar em grande proximidade física e temporal.

2. O analista de negócio fornecer a explicação da funcionalidade desejada em amplitude e dispara imediatamente o trabalho do desenvolvedor e do analista de teste.

3. Com os primeiros protótipos (ainda em papel) e as primeira histórias de usuários (em formato A5 ou rascunho em papel), o desenvolvedor e o analista de testes já podem começar a fazer pequenos códigos e casos de testes.

4. Enquanto o restante do seu time começa a dar vida ao seu caso, o analista de negócio se aprofunda na documentação necessária. Os casos de exceção são representados e as mais regras de negócio emergem. Estas novas informações habilitam o time a fazer mais, e mais código e casos de testes executáveis emergem.

5. Em base diária, as interações se intensificam e o contínuo feedback entre o analista de teste, desenvolvedor e o analista de negócio aperfeiçoam a documentação. A documentação cresce a cada dia, dentro do nível apropriado à realidade de cada organização.

6. No fim do sprint, as histórias que couberam no escopo tem seu código executável e testado e a documentação realizada que reflete exatamente o que foi construído. A isso chamamos de documentação AS-BUILT. Lógico, isso existe muita disciplina. Devemos lembrar  times ágeis tem como a característica #1 a DISCIPLINA. Sem disciplina em base diária, o modelo acima não ocorre. Se o modelo acima não ocorre, temos um time frágil trabalhando.

E qual o nível da documentação de um time ágil?

Não existe o nível certo. Existe o nível apropriado para a sua realidade e você e o seu time são as únicas pessoas no planeta Terra que tem condições de dizer isso. O que podemos dizer, em linhas gerais, que se a sua organização trabalha com times distribuídos ou está sujeito a normas regulatórias mais fortes como CMMI, ISO, ITIL ou SOX , você precisará formalizar mais coisas que pequenos times de produtos em startups que estão construídos MVPs O que observamos, de forma geral, é que regras de negócio tendem a gerar mais valor que as próprias interações de casos de uso (fluxos). Temos observado também que protótipos, áudios e vídeos também tem obtido grande adesão nos últimos anos. A gravação de entrevistas com usuários, por exemplo, tem se mostrado um instrumento importante para reduzir os custos no desenvolvimento de software. Observamos também a ênfase em trabalhar em mais profundidade documentos centrais de projeto, como o documento de visão do produto ou o documento de arquitetura de software.

Descrever, ao invés de prescrever, é o modelo para tratar o desenvolvimento de projetos complexos

No desenvolvimento tradicional de software, times de analista de negócio trabalham de forma isolada em silos (ou andares) e prescrevem a realidade futura em enormes documentos distantes fisicamente e temporalmente das pessoas que os irão implementar. Esta premissa epistemológica, que o mundo é ordenado e controlado no espaço e no tempo, não pode ser estar mais longe da verdade quando vamos abordar temas complexos. A verdade sobre a construção de um produto não pode ser prescrita, a não ser que você tenha poderes mágicos. A verdade do seu produto somente pode ser construída e representada à medida que as interações sociais entre as pessoas ocorram e que o software entregue em base diária provoque reflexões sobre os seus usuários para determinar o que deve ser mantido, o que ser alterado e o que será removido. A natureza de produtos complexos é orgânica e a documentação AS-BUILT respeita esta natureza. A natureza prescritiva, por outro lado, mostra-se ingênua. É por isso que times que vão apresentar seus produtos depois de meses de trabalho isolado no laboratório seguindo ordens escritas em documentos gigantes normalmente recebem feedbacks negativos dos seus clientes, geram retrabalho para si mesmos e aumentam em muito o tempo e o custo de um projeto.


Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *