Olá! Neste vídeo vamos falar sobre a relação entre metodologias ágeis e documentação de software. É comum ouvirmos as pessoas afirmando que em projetos ágeis não tem documentação.
O termo ágil é até usado muitas vezes como desculpa para não documentar. Será que isso está certo? Bom, Bom, existem mesmo muitas diferenças entre o papel da documentação nos projetos tradicionais e nos projetos ágeis. E realmente, a gente tem uma tendência nos projetos ágeis de ter menos documentação. É só a gente lembrar que o próprio Manifesto Ágil diz que software em funcionamento é mais importante do que uma documentação abrangente.
A documentação então não vai ser uma prioridade nos projetos. Mas isso não quer dizer que as metodologias ágeis sejam contra a documentação, nem que produtos desenvolvidos de forma ágil não sejam documentados. O que acontece é que a documentação é encarada de uma forma diferente, e é isso que a gente vai explorar nesse vídeo. Para entender melhor essa diferença, vamos dar uma olhada primeiro no papel da documentação nos projetos tradicionais.
Primeiro, as necessidades e desejos do cliente são mapeadas por uma análise de requisitos, que então define e documenta o que o software deve fazer para atendê-los. O conjunto de toda essa documentação forma a especificação de requisitos do produto. Além de definir e detalhar o que o software deve fazer, esse documento serve também como uma espécie de contrato entre o cliente e o desenvolvedor. Lá no final, quando o produto é entregue, qualquer comportamento diferente do esperado é considerado um defeito. Isso é feito para proteger o cliente, que ele quer a garantia de receber aquilo que ele pediu.
E também para proteger o fornecedor, que não quer ser obrigado a entregar nada além daquilo que foi especificado. A especificação é usada também para comunicar essa definição a quem vai desenvolver o produto. Como geralmente quem especifica?
não é a mesma pessoa que desenvolve, a documentação é quem faz essa comunicação. Num processo tradicional, o desenvolvimento é geralmente dividido em etapas sequenciais. Primeiro, um arquiteto de software analisa os requisitos, e a partir dessa análise define e documenta um desenho para a solução. Geralmente isso é feito na forma de modelos em notação UML.
Essa documentação é então entregue ao desenvolvedor, que vai efetivamente implementar a solução, usando como referência a especificação dos requisitos e o desenho que foi definido. Você já deve ter percebido aqui o padrão que se repete nessa abordagem tradicional. A documentação é feita sempre para definir o que deve ser desenvolvido, antes de desenvolver.
Ela é usada como uma especificação, como um insumo para o que precisa ser feito. E lá na frente, quando aquilo já tiver sido desenvolvido, essa mesma documentação é usada como referência para a consulta. Por exemplo, se entra uma pessoa nova na equipe, os documentos vão ajudar essa pessoa a entender o funcionamento do produto, as suas regras.
Esse é um ciclo de vida típico da documentação dos processos tradicionais. Ela serve para definir e detalhar o que precisa ser feito, para comunicar essas informações e para manter uma base de conhecimento sobre o projeto para referência futura. Mas qual é o problema em documentar dessa forma?
Na verdade, tem vários. Primeiro, a gente está usando a documentação como um meio principal de comunicação. E a gente sabe que a linguagem escrita não é a forma mais eficiente de comunicar uma ideia. Segundo, Se comunicar por escrito já é difícil por natureza, documentar para definir e transmitir de forma precisa todos os detalhes técnicos de um produto de software é mais difícil ainda.
Para tentar lidar com isso, a gente cria documentos e modelos cada vez maiores e mais detalhados. Tanto que até virou moda há alguns anos investir em formas de tentar gerar código automaticamente a partir dos modelos em UML de tão detalhados que eles eram. Só que isso gerou outro problema.
Se a gente quer usar... essa mesma documentação como referência futura, isso significa que a gente vai precisar manter tudo isso consistente durante o projeto. E também depois, durante toda a vida do produto. E não é nada fácil fazer isso com uma documentação tão detalhada.
Principalmente porque é quase sempre inevitável lidar com alterações. Requisitos mudam, decisões de desenho mudam. Cada alteração tem que ser refletida em todos os artefatos e para fazer isso com segurança, a gente tem que recorrer a ferramentas até sofisticadas para manter a rastreabilidade entre todos eles.
Mesmo com essas ferramentas, o custo de alteração geralmente é alto e sempre vai ter o risco de a gente ter deixado para trás alguma informação inconsistente. Nos projetos ágeis, a abordagem é outra. Assumimos que documentos e modelos são apenas uma das formas possíveis de comunicação, mas existem outras. Por exemplo, a comunicação verbal, natural e direta.
Na maior parte das vezes, é muito mais fácil transmitir uma ideia por meio de uma boa conversa, frente a frente, do que tentar expressá-la por escrito. Por isso, as metodologias ágeis procuram incentivar essas formas mais naturais e espontâneas de comunicação e reduzir ao máximo a necessidade de documentação. Só que essa comunicação informal e direta também vai ter suas limitações e é por isso que a gente precisa tomar alguns cuidados para que essa abordagem funcione. Primeiro, comunicação informal e direta pode funcionar bem em uma equipe de 5 pessoas, mas não em uma equipe de 50. Por isso, a gente trabalha com pequenas equipes, onde todos trabalham próximos no mesmo espaço físico. Outra coisa que ajuda muito é o desenvolvimento em pequenos incrementos.
Se as histórias de usuários são pequenas, é mais fácil comunicá-las conversando sem ter que recorrer a uma documentação por escrito. Quando surge alguma dúvida quanto a detalhes de uma funcionalidade, a gente precisa ter também alguém por perto que saiba explicar esses detalhes e alguém que também consiga tomar decisões sobre prioridades e trade-offs. No Scrum, essa é uma das funções do Product Owner, ou PO.
No XP, isso é feito com o envolvimento do cliente real. Por falar no cliente, um dos principais valores ágeis é o de tentar priorizar a colaboração com o cliente no lugar da negociação de contratos. Se a gente consegue seguir esse valor, a gente reduz a necessidade de criar documentos só para proteger as partes. E por último, algumas práticas típicas de metodologias ágeis como desenho simples, o desenvolvimento dirigido a testes ou TDD e a refatoração, elas tendem a tornar o código mais legível.
e também mais autodocumentado. Tudo isso vai nos ajudar a reduzir a necessidade de documentação. Mas claro que não vai eliminá-la totalmente. A gente vai ter várias situações em que a documentação vai ser muito útil e importante.
Mas quais são essas situações? As metodologias ágeis têm um enfoque muito prático para definir quando vale a pena documentar. É uma equação simples. A gente documenta sempre que o benefício e o valor de ter essa documentação superarem o custo.
E o custo aqui envolve tanto o custo de criar o documento, como o custo de mantê-lo atualizado depois. Aqui já temos um ponto importante. Nem todos os documentos e modelos criados precisam ser necessariamente mantidos. Por exemplo, a gente pode criar um diagrama em 1ml para nos ajudar a tomar uma decisão de desenho. O custo de criar geralmente é baixo.
A gente pode fazer diagramas até mesmo rabiscando em papel ou desenhando em um quadro. E podemos também, claro, fazer isso em uma ferramenta de modelagem. Mas pode ser que depois que a gente tomar a decisão que a gente estava buscando, não valha mais a pena tentar manter esse diagrama até o final da vida do produto.
Nesse caso, se o custo de manter não superar o benefício que ele vai nos trazer, a gente descarta. A ideia é tentar manter somente aquilo que vai ser realmente útil. Mas isso é muito diferente de não ter documentação.
Por exemplo, imagine que uma equipe ágil vai desenvolver um produto sob encomenda para um cliente. Esse cliente quer que no futuro... A sua própria equipe interna assuma a manutenção desse produto.
Por isso, para ele é importante receber não só o produto, mas também uma documentação técnica, que vai ajudar a sua equipe a assumir a manutenção lá na frente. Isso é perfeitamente possível e não tem nenhum conflito com os valorizagens. A documentação, nesse caso, tem valor para o cliente e isso justifica o custo de criá-la. Só que a forma de produzir essa documentação, essa sim, vai ser um pouco diferente. Na abordagem tradicional...
já vimos que geralmente a gente documenta para definir aquilo que vai ser desenvolvido, antes de desenvolver. No final, quando o produto é entregue, a gente entrega também essa documentação que foi feita para guiar o desenvolvimento. Bom, parece razoável.
Só que aqui a gente está documentando as coisas enquanto elas ainda estão sendo definidas. E esse é o pior momento para documentá-las. Por quê? Porque elas ainda estão muito instáveis. Isso significa que mesmo que o custo para criar a documentação seja baixo, o custo para manter...
ter pode ficar muito alto. Por isso, no desenvolvimento ágil, a abordagem vai ser diferente. A gente não documenta antes de desenvolver.
Geralmente, a gente tem umas pequenas descrições que identificam quais são os itens que devem ser desenvolvidos. Essas descrições costumam ser chamadas de histórias de usuário. São muito simples, geralmente uma única frase feita em linguagem de negócio.
Mas é claro que numa única frase, a gente não vai conseguir definir todos os detalhes de uma funcionalidade. Mas isso é até intencional. O objetivo da história não é documentar, é simplesmente identificar o item que vai ser desenvolvido.
Quando a história for selecionada para ser feita em uma iteração, ou num sprint, no caso do Scrum, aí sim ela vai ser discutida mais detalhadamente e desenvolvida, tudo isso na mesma iteração. E como nesse caso o cliente precisa também de uma documentação entregue, a gente vai produzir e entregar não só o produto funcionando no final da iteração, mas também a documentação necessária. A gente pode até definir precisamente quais são os critérios para aceitação, tanto do produto quanto dessa documentação. Isso não tem nenhum conflito com os valores ágeis.
E como aqui a gente está tratando a documentação como um resultado e não como um insumo, a gente consegue reduzir muito o custo de manter. É isso. Mas se a gente tentar resumir tudo o que a gente viu até aqui em apenas três pontos, a gente pode dizer, primeiro, que o desenvolvimento ágil reduz a necessidade de documentação.
Segundo, os métodos ágeis não são contra a documentação, desde que elas gerem um valor que justifique o seu custo. E por último, nos casos em que a gente decide documentar, Essa documentação não é tratada como um insumo para o desenvolvimento, e sim como um resultado do projeto. Bom, é isso.
O papel da documentação nos projetos ágeis.