A importância da documentação funcional na Metodologia Ágil

Objetivo

Mostrar a importância da documentação funcional dentro da metodologia ágil e sugerir um processo para que ela seja criada com cautela e qualidade.

O Problema

Você é chamado para ser o Analista Funcional de um sistema. Este sistema irá controlar um aparelho que emitirá radiação em pessoas que estão fazendo tratamento de câncer. A empresa utiliza a metodologia ágil para o desenvolvimento de software. Neste cenário, você estaria seguro em fazer a documentação do projeto durante o início de cada sprint?

E falando de um projeto mais simples, como um cadastro de cliente. A documentação produzida no início do sprint é a ideal? Tudo o que você documenta ou é produzido pela equipe durante o sprint realmente será utilizado?

“Por que” e “para quem” você cria o Documento?

Você já parou para pensar nisso? De verdade? Lendo um artigo escrito pelo arquiteto Michael Nygard, ele se diz surpreso com a quantidade de processos que ele encontra onde não existe um consumidor final. Dinheiro jogado fora. Nygard sugere que, antes de começar qualquer processo, você tenha em mente o fim dele. “Begin With the End in Mind”.

Começando com o Fim em Mente: O que produzir?

Como comentei, primeiramente é preciso entender para que está sendo criada a documentação do projeto. Vamos pensar no fluxo de trás para frente. Para isso existem algumas perguntas sugeridas por Michael Nygard que ajudam nesta reflexão:

1. Quem será o consumidor da documentação?
2. O que eles precisam?
3. Como você vai entregar a eles?
4. Como você vai produzir?
5. De onde você irá tirar as informações para criar a documentação?

Com as respostas em mãos já é possível ter uma idéia mais clara do que é necessário criar.

Documentação de Acordo com a Natureza do Projeto

Dentro do mundo ágil, como criar uma documentação para sistemas que não podem tolerar falhas? Esses sistemas, em caso de falha, podem desencadear prejuízos milionários às empresas. Para sistemas desta natureza deve ser obrigatório a presença de, no mínimo, um Analista Funcional para criação de uma documentação de qualidade e também fazer alguns ajustes na metodologia aplicada.

Algumas palavras a respeito da Metodologia de Desenvolvimento

Dependendo da metodologia de desenvolvimento que está sendo utilizada, a documentação é criada em momentos diferentes. No modelo cascata a documentação é criada antes do desenvolvimento do projeto, sendo ela madura mas com grande chance de estar desatualizada para as necessidades do cliente, uma vez que essas necessidades mudam em pouco tempo. Já no modelo ágil, a documentação é criada no início de cada sprint, com pouca chance de estar desatualizada para o desenvolvimento (acreditem, elas mudam em dias). Em contrapartida, as documentações criadas no início de cada interação ágil tem uma tendência maior de possuir algum erro, algum fluxo esquecido, alguma regra que ninguém se atentou, em sua maioria por questão de tempo, ao contrário da documentação criada com a metodologia cascata. A documentação do modelo cascata também está sujeita a esses tipos de erros mas com menor probabilidade, uma vez que tempo gasto em sua criação é maior. Também devemos ter em mente que a capacidade do profissional que está atuando na criação do documento influencia na qualidade do produto final.

O melhor dos cenários é o meio termo entre os dois mundos no que diz respeito a documentação. Sou a favor da metodologia ágil, mas as vezes dá a sensação que algumas documentações criadas no início dos sprints não estão cobrindo tudo o que deveriam e, em outros momentos, noto que o Dono do Produto precisa de mais tempo para definir certas regras. Dependendo da natureza do projeto, isso pode ser um risco enorme.

Processo sugerido

De uma forma simplista, esta é a base do processo que sugiro para criação do documento funcional dentro da metodologia ágil:

1. Backlog
   Antes de iniciar o processo de desenvolvimento, o Analista Funcional deve acompanhar o Dono do Produto (PO) ou o Analista de Negócios na criação do backlog do sistema, com todos seus critérios de aceite. A partir daí o Analista Funcional precisa entender o projeto como um todo, documentar este entendimento de uma forma superficial e apresentar ao time de desenvolvimento, tirando todas as dúvidas deste overview e nivelando o conhecimento entre todos. De uma forma resumida seria a apresentação das funcionalidades do sistema sem maiores detalhes. É com essas informações em mente que a base do sistema deveria ser arquitetada.
2. Documentação “Beta” do Sprint
   A mensagem principal deste artigo está presente neste item: Quanto menor for a aceitação do sistema a erros, maior o tempo que deve ser gasto na criação da documentação. O Analista Funcional precisa andar, ao menos, de uma a duas interações a frente da equipe, a fim de criar uma documentação completa, madura, validada e, consequentemente, com menos probabilidade a erros. Quanto mais critico for o projeto mais interações a frente o Analista Funcional deveria ficar.
3. Alinhamento com Líder Técnico
   Após criar a documentação de um sprint, o alinhamento com o Líder Técnico precisa ocorrer com o propósito de antecipar possíveis imprevistos, como por exemplo alguma limitação técnica para o desenvolvimento de uma funcionalidade.
4. Validação da Documentação
   Com a documentação inicial criada e alinhada com o Líder Técnico, é hora de fazer a validação com o Dono do Produto, para que não exista impedimento no que diz respeito a regra de negócio. Feito isso, podemos considerar que temos uma documentação funcional pronta para um sprint.
5. Planning
   Na metodologia ágil, qualquer documentação que precisa ser criada (fora o backlog) deveria ser feita durante o planning. No processo sugerido, dentro desta etapa o time já teria toda documentação funcional em suas mãos e o planning serviria somente para entendimento da documentação entre o time e o PO.

Conclusão

Para fechar o artigo, a conclusão que gostaria de passar é que quanto menor a aceitação do sistema a falhas, melhor planejado e com menor tolerância a mudanças o desenvolvimento deve ser feito. Se for um sistema simples, a metodologia ágil cai como uma luva, caso contrário precisamos criar esta adaptação.

Como comentou meu colega Abu (blogdoabu.blogspot.com.br), que faz Agile Coaching em empresas como Oi Internet, Walmart e Terra, a questão não é binária, ter ou não ter, mas sim ter o que agrega valor.

Espero que tenha ajudado e fiquem a vontade para comentar, sugerir modificações do processo e postar críticas construtivas.

Referências:

http://www.infoq.com/news/2014/01/documentation-agile-how-much
http://pivotallabs.com/minimum-viable-deliverable/
http://www.scrumalliance.org/community/articles/2013/december/essential-valuable-timely-documentation
http://thinkrelevance.com/blog/2013/10/07/begin-with-the-end-in-mind
http://stackoverflow.com/questions/1110293/building-a-life-critical-system-using-agile
http://businessanalystlearnings.com/blog/2013/4/21/traditional-to-agile-the-role-of-bas-in-agile-projects
http://everypageispageone.com/2013/11/25/dont-lean-on-developments-agile-process/

[Crédito da Imagem: Metodologia Ágil – ShutterStock]