Métodos ágeis e documentação de software

[Música] Olá nesse vídeo vamos falar sobre a relação entre metodologias ágeis e documentação de software é comum a gente ouvir 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 está certo 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 important 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 documentação nem que prodos desenvolvidos de for ágil não seam 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 um analista de requisitos que então define e documenta o que 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 no 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 pra 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 pro que precisa ser feito e lá na frente quando aquilo já tiver sido desenvolvido essa mesma documentação é usada como referência para 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 paraa referência futura Mas qual que é o problema em documentar nessa forma Na verdade tem vários primeiro a gente tá usando a documentação como 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 zeram 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 inevitvel lidar

com alterações requisitos Mud decisões deen mudam cada alteração tem que ser refletida em todos os artefatos e fazer ISO com seguran 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 da 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 as 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 numa equipe de cinco pessoas mas não numa equipe de 50 por isso a gente trabalho 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ário são pequenas é mais fácil comunicá-las conversando sem ter que recorrer a uma entaçã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 tradeoffs no scrum Essa é uma das funções do Product owner o 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 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 autod documentado 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 que são essas situações as metodologias ágeis tem 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 grama em

1 ml 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 numa ferramenta de modelagem Mas pode ser que depois que a gente tomar a decisão que a gente estava buscando não vale 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 aí com os valores ágeis a documentação Nesse caso tem valor pro 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 tá documentando as coisas enquanto elas ainda estão sendo definidas e esse é o pior momento para documentá-los 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 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 interaçã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 interaçã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 tá 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 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 documentação desde que elas gem 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 insumo pro desenvolvimento

e sim como um resultado do projeto bom é isso o papel da documentação nos projetos [Música] ágeis [Música] h