Considere a seguinte situação: a equipe de desenvolvimento recebe a seguinte solicitação: “Os usuários antigos do sistema devem ser removidos, afinal todos os que não trabalham mais na empresa não precisam estar em nossa base de dados.”
Após ouvir uma solicitação destas, no modelo tradicional, abre-se uma solicitação e possivelmente um programador executará uma rotina para apagar todos os usuários antigos, deixando na base apenas os ativos.
Já em modelagem ágil, esta solicitação será analisada pela equipe, que a classificará dentro da lista de requisitos a serem atendidos pela equipe de desenvolvedores, avaliando sua prioridade e motivo. A equipe estará atenta à solicitação e considerará com o solicitante outros fatores que ele possa desconhecer, avaliando as consequências que tais ações podem desencadear. A equipe considerará, entre outras coisas, que há no sistema um log de movimentação que registra, com base no cadastro de usuário, qualquer alteração ocorrida na base como um todo. Então, vão concluir que o cadastro não pode ser excluído e que basta apenas que se adicione um atributo de ativo ou inativo. A partir disso, podem-se omitir os inativos dos relatórios e das telas, mas nunca perder a informação de quem efetuou a movimentação.
Como é possível notar, é necessária uma percepção adequada de cada situação apresentada.
Há dois fatores básicos para se alterar os requisitos de um sistema:
- entender a real necessidade da alteração;
- manter a equipe ciente do que está acontecendo.
Segundo Cockburn (2001), a novidade nos modelos ágeis não está nos métodos ágeis, mas no envolvimento de pessoas que participam do sucesso do projeto e que estão focadas na capacidade de gestão do negócio.
Normalmente estes modelos ficam expostos à equipe e às pessoas interessadas. É muito comum a utilização de planilhas eletrônicas compartilhadas que contenham todos os modelos em análise ou aplicação.
Há apenas um perigo que se deve considerar quando os modelos ágeis são analisados, que é o excesso de informações desnecessárias.
Imagine um mapa que o guiará para chegar ao seu destino. Se nele você encontrar um número excessivo de detalhes, ele pode se tornar ineficaz. Como, por exemplo, mostrar a quantidade de bueiros, postes, casas ladrilhadas ou não, prédios com elevadores ou não, qualidade das calçadas do trajeto e a quantidade de faixas de pedestres existentes nas proximidades... informações totalmente desnecessárias, não é mesmo? Assim como este excesso de informações torna o mapa ineficaz, o excesso de itens a serem modelados pode tirar a agilidade do modelo. Neste momento, o uso de abstrações torna-se imprescindível.
