Vou usar uma situação que aconteceu em um projeto que eu trabalhei recentemente para mostrar como um método ágil de desenvolvimento e um contrato de escopo negociável lidam (ou melhor, lidariam) bem com requisitos que mudam/evoluem. Um dos requisitos do sistema era permitir que o usuário cadastrasse uma ficha. Em outro momento, um usuário iria preencher essa ficha no sistema. Antes do sistema existir, o cliente utilizava o Excel para criação e preenchimento dessas fichas. Simplificando um pouco, uma ficha continha quadros que por sua vez continha itens. Itens podiam ser de diversos tipos: campo texto de livre preenchimento, seleção única, seleção múltipla, etc.
O projeto adotava oficialmente RUP como metodologia de desenvolvimento. Mas, na prática, era um verdadeiro cascata. Longas fases iniciais onde todos os requisitos eram detalhados de forma exaustiva. Logo em seguida, o modelo de dados era totalmente especificado (por questões que estavam além do controle de nós desenvolvedores, o foco da modelagem eram os dados do sistema e não o modelo de domínio do sistema). Assim, o modelo de dados da ficha havia sido especificado nessas fases iniciais do projeto, utilizando como base algumas fichas de exemplo que o cliente utilizava no dia a dia das suas atividades naquela época. A implementação dessa funcionalidade só aconteceu meses depois. Pouco após ela ficar pronta, descobriu-se que o cliente não estava mais usando as fichas que foram utilizadas para definir o modelo de dados. As fichas tinham evoluído para uma nova versão. Pior, o modelo de dados existente não suportava essa nova versão das fichas.
Aí é que começam os problemas. A empresa onde eu trabalhava simplesmente não podia aceitar essa mudança de requisito. O contrato definia prazo, custo e escopo e estipulava multas caso alguma dessas variáveis não fosse atendida. Se a empresa aceitasse implementar a mudança, certamente estouraria prazo/custo e seria multada. Por outro lado, a funcionalidade, da forma como estava implementada, simplesmente tinha valor zero para o cliente. Não servia para nada. Percebe-se que a metodologia em cascata junto com o contrato fixo criou uma situação onde ambos fornecedor e cliente saem perdendo. Fornecedor e cliente até poderiam usar documentos do projeto, contratos, etc. para definir de quem é a culpa para tal situação. Mas isso não resolveria o problema que é ter a funcionalidade implementada de forma que traga valor para o cliente. Para contornar o problema, cliente e fornecedor teriam que sentar para renegociar o contrato, aumentando prazo/custo ou talvez adiando a implementação da funcionalidade para uma futura versão do sistema. Certamente uma solução pouco satisfatória e que ainda por cima geraria um atrito grande na relação cliente/fornecedor. Não sei dizer como foi resolvido o problema, pois saí do projeto antes.
Por outro lado, se fosse adotado um método ágil junto com um contrato de escopo negociável, a situação narrada não seria um problema, e sim algo normal, esperado de acontecer. Assim, a funcionalidade seria implementada no menor tempo possível e de forma que agregasse valor para o cliente. Vejo dois cenários possíveis.
No primeiro, quando a funcionalidade fosse priorizada para implementação, a nova versão da ficha em Excel já estaria sendo utilizada pelo cliente. Como seria somente nesse momento que a funcionalidade seria detalhada, a modelagem já seria feita baseando-se na nova versão. Ou seja, ao deixar a modelagem desta funcionalidade para que fosse feita no Último Momento Responsável (Last Responsible Moment), evitaria-se um retrabalho.
No segundo cenário, a funcionalidade já estaria implementada quando a versão da ficha fosse alterada. Nesse caso, surgiria uma nova história para adequar a ficha à nova versão, que seria priorizada juntamente com as demais histórias restantes. Provavelmente ela seria priorizada logo na iteração seguinte, tendo em visto o valor que traz para o cliente. O retrabalho não teria sido evitado, mas a alteração seria algo trivial e não demandaria uma burocracia excessiva nem geraria atritos fornecedor/cliente. Isso porque métodos ágeis em geral criam um ambiente que favorece mudanças, ao contrário de metodologias mais tradicionais que tentam evitar esse tipo de mudança a qualquer custo.
Posted by Guilherme Cirne 
Posted by Guilherme Cirne 
Posted by Guilherme Cirne 