Que tipo de documentação eu preciso?

Respondi essa pergunta semana passada no Formspring. Uso User Stories? Uso Diagrama de classe? Uso Casos de Uso? A pergunta, na verdade, é qual a documentação ideal em um processo de desenvolvimento de software. Que tipo de documento é preciso para iniciar o desenvolvimento?

Não existe documento ideal. E você não precisa de nenhum documento pra iniciar o desenvolvimento.

Pronto, dei argumentos para todos os extremistas defensores do desenvolvimento em cascata. Lá vem eles de novo dizer que em projetos ágeis não há documentação. E não foi o que eu disse. Eu disse que você pode iniciar o desenvolvimento sem nenhum documento. Ainda assim, como isso é possível?

Amigos, libertem-se da ilusão do processo em cascata, e de que vocês conseguem documentar antes de executar. Libertem-se da ilusão de que vocês são capazes de prever o que vai acontecer, e prever o que vão precisar daqui a alguns dias. Vocês só vão saber do que vão precisar em projeto de software quando realmente precisarem. Talvez vocês tenham uma boa ideia sobre isso depois de terem feito alguns projetos com o mesmo time, com a mesma tecnologia, e que trate do mesmo negócio (ou com pouca variação nestes itens). E mesmo assim, vocês vão precisar ajustar um pouco em cada projeto, mesmo depois de toda essa experiência acumulada.

Qual documento você realmente precisa para começar? Nenhum. Você até pode começar com algum que a empresa sugeriu, ou algum que algum membro do time sugeriu, mas isso não faz diferença. Inicie o projeto, isso é que interessa. Se você realmente fundamentar o projeto em princípios ágeis, você vai ter um projeto em que a transparência reina, e você vai ter a chance de realizar inspeções constantes no processo, se adaptar quando encontrar algo que não está funcionando e reforçar o que está funcionando. Assim, se começar com nenhum documento, você provavelmente vai perceber que um ou outro documento está fazendo falta, e vai ter a chance de inclui-lo. Isso pode aparecer dentro dos diversos ciclos de inspeção que você tem.

Quando você está programando em par pode perceber que um documento pode ser útil para comunicar melhor um design, ou talvez um cartão CRC. Às vezes na reunião diária pode ser que alguém precise entender melhor um requisito que você conhece, e daí talvez você crie um caso de uso para explicar melhor isso. Pode ser que o arquiteto corporativo demande algum diagrama arquitetural da aplicação, então vocês colocam isso no backlog do projeto e entregam para ele no final de uma iteração.

Mas nada disso importa, nenhum dos documentos mencionados acima importa. O que importa é que seu time esteja aberto a esses feedbacks que inundam qualquer projeto de software, que saiba aproveitá-los. A documentação que você precisa vai naturalmente emergir, vinda da comunicação do time, das interações com o negócio, das necessidades técnicas, e de diversos outros fatores. Isso é o que eu chamo de documentação emergente.

É por isso que desenvolver software é um processo complexo e não linear, e portanto muito além da nossa compreensão total: há variáveis demais. Nosso objetivo é apenas impedir que ele se torne caótico, fazendo o máximo para mantê-lo apenas complexo. E os fluxos de inspeção e adaptação em ciclos curtos vão garantir isso. Isso é a base de um processo empírico de controle. E se aplica também à documentação. Faça apenas o necessário, decidindo sempre no último momento responsável (last responsible moment).

E os padrões corporativos? Devem ser um catálogo. Mais uma vez, padrões sem cenários são completamente inúteis.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.