Essa questão da documentação pode realmente trazer alguns impactos em alguma das partes interessadas. Aqui tivemos problemas com a aferição do software utilizando a técnica APF. Tivemos que ir ajustando o nível de documentação aos poucos devido a problemas para medir o software.
hoje, com a Alura e o Google Gemini
Oi Denivaldo,
À tpitulo de curiosidade, você poderia comentar como seria possível evitar essa situação em outros casos? ")
Olá Priscila, No nosso caso, o problema era que as histórias de usuário não tinham informação suficiente para que fosse possível medir o tamanho do software utilizando a Análise por Pontos de Função. Pois precisávamos de mais detalhes do requisito (algo como um caso de uso) e as telas do sistema, por exemplo. Então, para o nosso caso, a única forma de evitar o problema seria já fazer a documentação mais completa desde o início, nós começamos com pouca documentação e incluimos mais um documento e informações, até chegar num nível que consideramos aceitável. Mas, levando em conta o que preconiza a metodologia ágil, acredito que cada situação exigirá um nível de documentação diferente. Não sei se fui claro.
Oi Denivaldo,
Foi claríssimo! Obrigada por compartilhar. ^^
Gosto sempre de citar o Manifesto Ágil nesses casos, "Software em funcionamento mais que documentação abrangente". É bem claro que o software funcionando é o que gera real valor para o cliente, mas no Ágil não dizemos que a documentação é inexistente, mas não abrangente. Muito disso depende de como a equipe se sente confortável, e de como fazemos para ter as informações necessárias para o desenvolvimento. Será que um cliente presente não seria mais aproveitável do que uma documentação de 100 páginas? Gosto também do uso de diagramas, acho que facilitam o entendimento e as equipes costumam gostar.