Seja bem-vinda, manutenção!

É 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.

4 Responses to “Seja bem-vinda, manutenção!”


  1. 1 Fabio Nascimento 17/jul/2008 às 15\0345

    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!

  2. 2 Roger Leite 17/jul/2008 às 15\0356

    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

  3. 3 Thiago Silva 17/jul/2008 às 17\0554

    Demorou, mas postou!
    E o seu “porcaria”, para mim é “muito bom”! :)

    []’s

  4. 4 thiagoarrais 18/jul/2008 às 18\0644

    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!


Comments are currently closed.




%d blogueiros gostam disto: