Ágil não tem — Documentação

Da série #ágilnãotem quero falar um pouco sobre o tópico documentação. E trazendo o manifesto pra me apoiar na argumentação, lembro que…

“Software em funcionamento mais que documentação abrangente”

Essa semana, um time me chamou pra trocar uma ideia sobre uma estrutura de documentação que eles estavam elaborando para o projeto deles. O projeto na verdade poderia muito bem ser chamado de produto, pois é um dos contextos mais produtizados que temos na firma! O time tentava fazer um deXpara de um modelo da documentação que fazemos no waterfall para o ágil, num esforço genuíno de adaptação.

Eu fiz algumas provocações para gerar reflexão,

Propósito: Pra quê fazemos documentação?

Resposta que eles me deram: “Porque precisamos garantir que quem está chegando no projeto entenda o que temos.” (perfeito! ❤)

***Eu poderia ter ouvido: “Porque precisamos enviar a uma fábrica de SW o que deve ser feito.” Sim, isso ainda faz parte da nossa realidade. E nesse contexto eu entendo a necessidade de uma documentação mais detalhada, mas ainda assim penso num modelo um pouco diferente do que fazíamos antes (um BDD ou TDD, talvez), mas vai depender do contexto.

Contexto: Nesse produto temos time dedicado, com PO presente e SM atuante. Usamos JIRA e Confluence! A proposta deles consistia em usar o Confluence como uma repositório de documentos, trazendo detalhes técnicos das features para dentro da Wiki.

Proposta que eu fiz: Todo detalhamento da História ou da Tarefa devem estar dentro do próprio JIRA. O Confluence deve conter informações gerais como por exemplo um documento de arquitetura de aplicação, um documento de visão do produto, etc. O que nos leva ao próximo ponto,

Produto e não Projeto: Documentar produto também é diferente de documentar projeto, assim como a gestão de produto é diferente da gestão de projetos. Trouxe pra esse time a perspectiva de que eles tinham em mãos um produto completo e não só um projeto para implantar novas features.

Para eles valia mais pena ter no Confluence um documento de visão de produto, um roadmap, um repositório de regras de negócio, um mapa de épicos(com legenda de status colorido) e um documento de arquitetura de solução. Com esses 5 artefatos eles conseguem garantir que qualquer pessoa nova que chegue ao time consiga ter uma visão geral e um caminho de onde buscar detalhamento.

Dentro do JIRA eles teriam o detalhamento funcional e técnico das histórias e tarefas, e os critérios de aceite de cada uma delas. Referenciando as regras de negócio no Confluence sempre que fosse necessário. Eles combinaram de pensar a respeito e amadurecer a ideia.

Executando um framework ágil a fluidez da comunicação está garantida com as cerimônias e a construção da sinergia do time. A documentação não assume um papel de detalhar soluções, porque:

“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.” Manifesto Ágil

SIM, Existe documentação no ágil! Só não trazemos a carga de manutenção dessa documentação ao nosso dia a dia, porque:

“Software em funcionamento mais que documentação abrangente”

Como eu sempre digo, ter o manifesto interiorizado te garante pensar em melhores soluções com as ferramentas que você tem!