É bastante comum ver organizações que costumam desenvolver software em cascata espernear quando chega a hora de implantar e colocar os sistemas em produção. Depois que tudo está instalado e funcionando a todo vapor elas acabam entrando em modo bombeiro e passam simplesmente a apagar um incêndio atrás do outro, sem saber muito o que fazer e como organizar seus esforços de manutenção.
Isto costuma acontecer porque a abordagem de desenvolvimento delas simplesmente não está adaptada à manutenção. Ela foi otimizada para um cenário (completamente fictício, diga-se de passagem) onde não há vida após a entrega do sistema, onde os clientes não mudam de idéia e onde não acontecem requisições de mudança depois que o software está pronto.
Não importa quanto alguém se dedique à tarefa. Ninguém consegue fazer a água da cascata cair para cima.
A abordagem oposta, obviamente, é otimizar para a manutenção, isto é, estar pronto para começar pequeno, mudar sempre que necessário, consertar o software aos poucos e torcer para que um dia ele não precise mais de conserto. A proposta Ágil começou com experiências neste sentido, tomando emprestado da filosofia release early, release often e preferindo usar o próprio software para comunicação entre os clientes e a equipe de desenvolvimento ao invés de documentos e diagramas. Num certo sentido, equipes ágeis tomam a manutenção como modo de operação normal no lugar do desenvolvimento puro. Preferem desenvolver uma solução completa e usável para um problema pequeno rapidamente para que possam dar as boas vindas à manutenção o mais cedo possível. Enquanto os clientes não tem uma peça real de sofware para usar e experimentar, suas sugestões são só um pouco melhor do que especulação.
Esta não é uma idéia tão louca no fim das contas. Pensando bem, da segunda linha de código para a frente tudo é manutenção.
Pois é, até que estávamos indo bem aqui onde trabalho já era o segundo projeto que conseguimos introduzir algo de ágil…
Mas aí aconteceu o pior, tivemos que herdar um projeto de uma outra empresa e o que a outra empresa fez foi apenas “rabiscos”, uma documentação extensa, mas tão vazia quanto seu tamanho e aí bingo!
Estamos “Waterfall” novamente, é uma droga, e o pior é que nosso cliente espera que continuemos de onde o projeto parou.
Vai ser um parto só.
Mas seu texto valeu pra me lembrar como não devo proceder.
Abraços.
Fabio Nascimento (www.twitter.com/fnascimento)
P.S.: Como você mencionou no twitter, eu retruco, o texto não ficou uma “porcaria” não!
Sensacional ! Os primeiro paragrafos descrevem exatamente meu sofrimento diário. É interessante notar que, as empresas “cascatas” adotam processos mágicos, onde uma tarefa é “transformada” em n documentos, ai quando entram em modo bombeiro (e com certeza sempre entram!), adotam o modo patada, pois é crucial que sistema em produção não fique parado.
Legal, ninguém é perfeito e muito menos nenhum processo, o problema é que o modo bombeiro e patada viram parte do processo, e a empresa continua com os mesmos erros e se orgulham do selo de CMMI.
Valeu pelo post !
[]s
Demorou, mas postou!
E o seu “porcaria”, para mim é “muito bom”!
[]‘s
Fabio, complicado continuar de onde parou quando não existe “onde parou”. Afinal de contas, projetos feitos em cascata não produzem software funcionando tão cedo e não se tem efetivamente um estado anterior do sistema.
Eu poderia até apostar que essa empresa de que vocês herdaram o sistema “se orgulha do selo de CMMI”, como lembrou o Roger.
Boa sorte para você, cara!