1.Introdução

A visão clássica de desenvolvimento de software tem a documentação como peça chave para a manutenção de software, principalmente a parte de requisitos do sistema. Enquanto isso, a visão ágil de desenvolvimento de software tem como chave para a manutenção o próprio código do software que receberá maior atenção para sua qualidade. Sendo assim, a documentação perde parte de sua importância na manutenção dos sistemas segundo o manifesto ágil e os desenvolvedores passam a buscar uma maior qualidade para o código.

“Supostamente, a documentação formal deve descrever o sistema e, assim, tornar sua compreensão mais fácil para as pessoas que fazem as mudanças. Porém, na prática, a documentação formal nem sempre é atualizada, e, portanto, não reflete exatamente o código do programa. Por essa razão, os entusiastas de métodos ágeis argumentam que é um desperdício de tempo criar essa documentação e que a chave para a implementação de software manutenível é a produção de códigos de alta qualidade, legíveis. Práticas ágeis, portanto, enfatizam a importância de se escrever código bem-estruturados e investir na melhoria do código. Portanto, a falta de documentação não deve ser um problema na manutenção dos sistemas desenvolvimentos por meio de uma abordagem ágil.” (SOMMERVILLE, 2011)

Um dos argumentos usado pelos entusiastas desse tipo de desenvolvimento é a não correspondência da documentação conforme há atualizações no código. Ou seja, a documentação de um software nem sempre é atualizada acompanhando atualizações do código e, por isso, não pode ser utilizada como peça chave na manutenção de software, nem ter tanto valor. Mas quais problemas isso acarretaria?

2.Falta de Parâmetro para Medição de Custos de Manutenção

“No entanto, minha experiência em manutenção de sistemas sugere que o documento-chave é o documento de requisitos do sistema, que informa ao engenheiro de software o que o sistema deve fazer. Sem esse conhecimento, é dificil avaliar o impacto das mudanças propostas. Muitos métodos ágeis coletam requisitos informalmente, de forma incremental, e não desenvolve um documento coerente de requisitos. Nesse sentido, o uso de métodos ágeis pode tornar mais difícil e cara a manutenção posterior do sistema.”(SOMMERVILLE, 2011)

Segundo Ian Sommerville, o documento de requisitos é essêncial para ser possível avaliar impacto de qualquer alteração solicitada e assim facilitando a manutenção do sistema em questão. Os métodos ágeis valorizam o código de qualidade e muitas das vezes não geram documentos de requisitos de qualidade devida para serem usados como parâmetro em avaliações de custo de manutenções, então, a manutenção de software dentro do desenvolvimento ágil se torna cara.

3.Falta de Contrato Seguro com o Cliente

A documentação é desvalorizada durante todo o processo de desenvolvimento do software. A documentação formal de requisitos é substituida pela comunicação informal, o contrato com o cliente deixa de fazer uso da documentação formal como base e passa a fazer uso das horas de trabalho, e a manuteção de software tem como chave um código de qualidade, inutilizando a documentação.

“Outro problema não técnico – que é um problema geral do desenvolvimento e da entrega incremental – ocorre quando o cliente do sistema usa uma organização externa para desenvolver o sistema. O documento de requisitos do software é normalmente parte do contrato entre o cliente e o fornecedor. Como a especificação incremental é inerente aos métodos ágeis, escrever contratos para esse tipo de desenvolvimento pode ser difícil.

Consequentemente, os métodos ágeis têm de contar com contratos nos quais o cliente paga pelo tempo necessário para o desenvolvimento do sistema, e não pelo desenvolvimento de um determinado conjunto de requisitos. Enquanto tudo vai bem, isso beneficia o cliente e o desenvolvedor. No entanto, se surgirem problema, poderão acontecer disputas nas quais fica dificil definir quem é culpado e quem deve pagar pelo tempo extra, bem como os recursos necessário para a solução do problema.”(SOMMERVILLE, 2011)

Como a comunicação informal é mais valorizada do que registros formais dos requisitos na fase de análise do projeto e a documentação perde sua relevância para a manutenção do software, os métodos ágeis perdem a base parar contrato com clientes que é a documentação do software. Sendo assim, adotam a alternativa de cobrar e realizar contrato tendo como base as horas de desenvolvimento.

Apesar de ser uma alternativa para o uso da documentação formal como contrato entre cliente e empresa, as horas de trabalho não resguardam nenhuma das duas partes caso ocorra algum problema. Um contrato baseado em horas de trabalho não possibilitam definir de qual dos lados é a culpa nesses casos de problemas e não possibilitam julgar quem deve pagar pela quebra de cronograma.

4.Perda de Conhecimento

“Outro problema que pode surgir está relacionado à continuidade da equipe de desenvolvimento. Métodos ágeis dependem de os membros da equipe compreenderem aspectos do sistema sem consultar a documentação. Se uma equipe de desenvolvimento ágil é alterada, esse conhecimento implícito é perdido, e é difícil para os novos membros da equié construir o mesmo entendimento do sistema e seus componentes.”(SOMMERVILLE, 2011)

A falta de documentação formal torna o conhecimento do sistema e componentes limitado aos funcionários, e em uma empresa localizada em uma região com alta rotatividade de funcionários, a saída de um desses funcionário resulta em perda momentânea de informações sobre o sistema. Sendo assim, os novos funcionários necessitarão de compreenderem tudo através dos códigos.