Quase todo mundo que trabalha com computação ou ao menos trabalha próximo a uma equipe de TI já falou ou ouviu essa frase: “temos que refazer o sistema!”
Os motivos são variados:
- substituir tecnologia ultrapassada;
- nova plataforma;
- ou o motivo mais genuíno: o código estava ficando impossível de dar manutenção.
A consequência é um enorme número de sistemas sendo refeito. Por observação, eu calculo que 1/4 das pessoas em TI estão “refazendo” algum sistema (esse número não é estatístico ou científico).
Tenho observado dois erros graves nesse contexto:
Erro 1: Turn Off / Turn On
Ao refazer um sistema, deve-se evitar a troca brusca do antigo (switch) para o novo. O ideal é fazer uma transição contínua (dimmer), onde a nova versão vá substituindo a anterior aos poucos.
Uma decisão muito comum é: “vamos começar do zero e quando estiver pronto a gente troca o velho pelo novo”.
Existem vários riscos que surgem nessa decisão:
- demorar muito mais do que se imagina (já vi previsão de 3 meses se transformar em 3 anos)
- dividir a atenção do time entre o novo e o velho. Isso pode ser implementado de duas maneiras:
- subdividindo o time, o que pode levar uma das equipes a ficar desmotivada por trabalhar apenas na versão antiga;
- ou permitindo que todos mexam nos dois sistemas (opção um pouco melhor), mas nesse caso, o time enfrentará troca de contexto constante.
- novas funcionalidades tem que ser feitas no sistema antigo e novo, o que pode explicar porque a previsão é tão ruim, pois o escopo sempre cresce.
- enorme chance de incompatibilidade no momento do lançamento (e mais atraso por consequência).
- insatisfação crescente do usuário que não vê evolução no sistema que está usando (apesar de haver um esforço enorme por trás).
- insatisfação do usuário na hora do lançamento pois terá que aprender tudo de novo numa única tacada.
- para o sistema novo não há usuário real por muito tempo. Sem se expor, o sistema novo pode conter vários defeitos que só vão emergir na hora do uso.
Qual a sugestão então?
SOFTWARE ESTRANGULADOR
A ideia é construir um novo software que consiga conviver com o software legado, de preferência de maneira que o usuário tenha a impressão de que é um único sistema (mesmo que a interface de parte dele esteja mais bonita, por exemplo). A metáfora que o Martin Fowler usou para isso foi inspirado na botânica, como uma figueira que se enrosca em outra árvore e depois de anos a estrangula completamente [Martin Fowler, Stranger Application].
A nova versão do software deve ser igual a uma árvore estranguladora, envolvendo lentamente a versão anterior até sufoca-la de vez.
O objetivo da primeira Sprint deveria ser criar um mecanismo para que os dois sistemas convivam.
A dificuldade disso depende da implementação do sistema legado, alguns exemplos:
- se o sistema a ser substituído tiver uma arquitetura SOA fica tudo bem mais fácil;
- senão, a interceptação de chamadas é uma opção;
- numa arquiteura MVC, uma tática pode ser a substituição da interface (view), com troca gradual do Controler e do Model;
- a última opção é a comunicação dos sistemas via banco de dados.
Recomenda-se também cercar o seu sistema por testes de aceitação, de modo a garantir que o que estava funcionando permaneça funcionando.
Mesmo que essa decisão já tenha sido tomada, ou que seja impossível seguir as sugestões acima, ainda há um outro erro grave que pode ser evitado…
Erro 2: As funcionalidades devem ser mantidas
No cenário de refazer um sistema, é comum vermos um backlog criado a partir das funcionalidades do sistema antigo.
Como todo agilista deveria saber, começar o sistema com um escopo enorme e detalhado traz vários aspectos negativos:
- Não há prioridade e o foco fica na completude.
- Surge uma tendência de dividir o trabalho em etapas técnicas, pois o sistema só está pronto quando tudo estiver implementado.
- Itens em andamento descontrolado (Work In Progress não limitado).
- Aumento do custo de gestão pois a quantidade de itens já especificados é enorme.
- Repetir problemas de usabilidade que poderiam ser otimizados.
- Reimplementação de funcionalidades que não estão sendo usadas.
Qual a sugestão então?
Um bom backlog deve ser centrado no problema e não na solução.
Ou seja, as User Stories devem descrever problemas a serem resolvidos e, a medida que vão sendo fatiadas, as soluções vão emergindo (é inevitável que o sistema antigo sirva de inspiração, mas o ideal é que isso nem acontecesse).
Outro ponto importante é priorizar o backlog levando em consideração o motivo para refazer o sistema.
Começar pelo módulo problemático ou crítico antecipa a validação de suposições e por consequência diminui o risco.
RESUMO:
Ao refazer o sistema:
- Evite o desligar/ligar do antigo para o novo. Faça-os conviver simultaneamente!
- Não parta das funcionalidades do antigo para descrever o novo. O foco deve permanecer nos problemas que o sistema se propõe resolver.
Click here to read this post in english.
