ID-10070290Uma das questões que sempre me fiz desde que comecei a trabalhar com Scrum foi sobre a importância da documentação. Sabemos que o Scrum prega a entrega contínua de valor para o cliente. Porém, nem sempre o cliente enxerga a documentação do software que está sendo desenvolvido como algo de valor. No post de hoje, falo um pouco sobre a importância da documentação em projetos Scrum e sobre como incluir essa tarefa nas Sprints sem deixar de entregar valor para o cliente.

 

Por que documentar?

A metodologia Scrum é muito usada em projetos de escopo aberto ou onde exista incerteza sobre o que se quer do projeto. Nestes cenários as regras podem variar a cada Sprint, o que para muitos pode ser uma grande razão para não fazer documentação, pois teríamos muito trabalho jogado fora. Entretanto, ressalto que este tipo de cenário talvez seja onde a equipe mais vai precisar de documentos que descrevam o produto em desenvolvimento. Pois é neste ambiente que a equipe encontra mais dificuldade de ter sempre em mente o conhecimento sobre regras e características do produto, que variam muito.

Recentemente passamos por uma situação em que o cliente entrou em contato perguntando sobre um determinado comportamento do sistema, no qual ele atua como PO. Prontamente dissemos a ele: “Iremos verificar e já lhe damos um retorno!”. É nesse momento que acho que ter uma documentação ajudaria muito e pouparia tempo. Pois, pela falta de uma documentação precisamos acessar o código-fonte, ler algoritmos, ler sqls, etc para então ter um entendimento do comportamento do sistema na situação descrita pelo PO. Vejam que se tivéssemos uma documentação, este entendimento provavelmente seria alcançado mais rápido, pois no lugar de sqls e código-fonte, leríamos algum texto, ou diagrama, o que tornaria o entendimento mais imediato. Sem contar que o próprio PO poderia ter acesso à documentação e poderia sanar algumas dúvidas com mais independência.

Mas não só o PO tem dúvidas sobre o produto. A equipe de desenvolvimento por vezes também passa pela dificuldade de entender como determinada parte do sistema funciona. Muitas vezes precisamos destas informações na hora de estimar uma história, por exemplo.

Como incluir a documentação nas Sprints

Incluir histórias de documentação em uma Sprint não é uma tarefa muito fácil, pois nem sempre o PO dará prioridade a estas histórias. Uma forma de documentar sem deixar de entregar valor é incluir nas histórias da Sprint pequenas tarefas de documentação, de forma que esta seja feita de forma incremental e vá crescendo ao longo das Sprints. Essas tarefas pode ser um item de um “Checklist” executado ao final de cada história. No projeto em que participo atualmente como desenvolvedor, temos, a cada história, uma tarefa para checar a atualização do arquivo de versão, atualização/criação do javadoc, atualização dos scripts de banco de dados e atualização/criação de testes automatizados. Podemos incluir nesta tarefa a criação/atualização da documentação. Creio que o ideal seja que as tarefas de documentação tenha relação com sua respectiva história. É claro que quando vamos iniciar a documentação de um produto que já está a um tempo sendo desenvolvido, isso é mais difícil. Mas fazendo desta forma, a equipe consegue ao longo das Sprints gerar um material que cubra todo ou quase todo o produto em desenvolvimento.

Neste post busquei ressaltar a importância da documentação e mostrar uma forma de fazê-la sem prejudicar a entrega de valor para o PO ao final das Sprints. Vimos que a documentação pode ajudar muito o trabalho diário do PO e da própria equipe de desenvolvimento.

 E você? Faz documentação do seu projeto? Como inclui tarefas de documentação no seu projeto? 

Até o próximo post!