Eu atuei em alguns processos de migração como mudança de servidor aonde o código é mantido, alterado, compilado e gerado, como foi o caso do CSP, em alta plataforma (mainframe) para Visual Generator (visualgen-baixa plataforma). Outra forte migração foi a alteração de um sistema da base de IMS (base de dados da IBM mais antiga) para DB2 (banco de dados relacional mais atual) ambos em mainframe. O terceiro foi de COBOL Microfocus (cliente-servidor)para COBOL/DB2 no mainframe, aonde o gerente que atuou no projeto na época (eu era coordenador neste período) aceitou o argumento do cliente que seria somente um "copy/paste", isto é, simplesmente copiar e colar sem ter de alterar nada. Doce ilusão!! ... ou melhor AMARGA ILUSÃO!!!!
Vou descrever abaixo algumas sugestões e dicas utilizando estas situações citadas e reais para evitarmos ou pelo menos mitigarmos as situações citadas.
Definição do escopo
Um dos pontos mais importantes, senão o mais importante, é definir o escopo da alteração. Se faz necessário definir o que será feito, pois nunca é somente um "copy/paste" existem sempre módulos obsoletos, novas necessidades e acertos na migração pertinentes a nova linguagem, novo banco de dados ou interfaces com o usuário.
Deve ser levantado, escrito e aprovado pelo usuário este escopo e é importante deixar claro o que vai ficar de fora do escopo da migração. Desta forma o gerente de projeto fica calçado e com provas do que está aprovado para ser feito evitando o "scope creep", que pelo PMI, significa descontrole na definição do escopo causando atraso no projeto, estouro nos custos do mesmo e insatisfação do cliente. Outra prática importante citada no PMBOK é evitar o "gold plating", isto é, fazer aquele algo mais para agradar o cliente. Evite fazer o que não está no escopo pois este "a mais" custo tempo e dinheiro e não foi pedido.
Outro ponto importante não é considerar somente o escopo do projeto em termos de lógica de programação ou requerimentos solicitados pelo cliente mas também definição de requerimentos físicos como banco de dados, servidores, volume de dados, taxa de crescimento de dados, incompatibilidade de banco de dados ou sistemas operacionais e por ai vai.
Obviamente existem várias outras questões a serem abordadas. E tudo precisa ser feito aqui nesta fase de definição de escopo, que é onde o custo ainda é mínimo e o impacto, se acontecer algo errado, será menor.
Plano de Riscos
Durante a fase de definição de escopo e levantamento dos requerimentos acima é importante iniciar em paralelo o levantamento dos riscos do projeto. Devem ser levantados os riscos de cada requerimento, das alterações e suas possíveis consequências. Alguns riscos que podem surgir:
- falta de um especialista nas ferramentas existentes;
- usuário não tem a definição clara de suas necessidades;
- falta de um usuário dedicado ao projeto em suas fases críticas (por exemplo, levantamento e testes);
- falta de um estudo de viabilidade do projeto;
- objetivos não estão claros;
- time de projeto desconhece o sistema ou ferramentas;
Os riscos devem ser definidos, qualificados, quantificados e definidos os planos para mitiga-los (antes para evitar que ocorra) e para contingencia-los (caso ocorra, o que deve ser feito).
Toda dependência externa do projeto deve gerar um risco, por exemplo a dependência de um fornecedor externo ao projeto.
Falarei sobre riscos em detalhes em outra oportunidade.
Planejamento da Migração
Faça todo o planejamento necessário para a migração, GASTE TEMPO PLANEJANDO. Evite sair executando. Documente os acordos, busque aprovação dos requerimentos, crie um cronograma, planilha de custos, plano de qualidade, plano de configuração, plano de mudanças, plano de comunicação e plano de recursos humanos. Crie um database estruturado aonde vai manter estes dados, de preferência uma ferramenta já consagrada e execute backup diários dos mesmos.
Em outros posts entrarei em maiores detalhes mas abaixo falo de alguns essenciais e mais específicos para a migração.
Plano de configuração
Deve ser bem controlada a configuração dos módulos que serão alterados, para isso um plano específico para migração deve ser criado com bastante critério, evitando passar para produção módulos incorretos. Utilizar algo como um software próprio, como o Rational Clearcase ou em caso contrário uma planilha. Neste caso deve ter um responsável como o coordenador do projeto (Team Leader) ou um analista de configuração.
Segue abaixo um modelo que já utilizei e serviu perfeitamente:
- criar uma versão inicial como 1.0.0, que é a copia do atual em produção
- a partir deste criar versões em ambiente de teste da migração como 1.0.1, 1.0.2...
- caso exista algum alteração em produção a mesma deve refletir no ambiente de teste da migração e sua versão passaria a ser 1.2.0
- a partir deste criar versões em ambiente de teste da migração como 1.2.1, 1.2.2...
- quando for passar para produção a verrsão de migração para produção teremos a versão 2.0.0
Este é apenas um exemplo. Cada gerente pode criar seu modelo mas ele DEVE EXISTIR E SER BEM CONTROLADO pro um ÚNICO RESPONSÁVEL.
Plano de mudanças
Deve existir um plano claro de mudanças bem estabelecido e aceito pelos integrantes do time do projeto, usuário e principalmente pelo "sponsor", isto é, patrocinador do projeto.
Qualquer mudança no projeto deve ser analisada, avaliada, planejada e aprovada pelo "sponsor" ou pelo ele deve estar ciente da mesma. Todos os planos precisam ser refeitos e os impactos mensurados. Não deve ser aceito aquele famoso: "só vai alterar uma linha!!!"
Faça Backup
FAÇA BACKUP ! FAÇA BACKUP ! FAÇA BACKUP ! Sempre tenha um backup em mãos. Isto pode salvar muitas vidas. É sério !
Antes de começar o procedimento, faça cópia de tudo. TUDO MESMO ! Banco de dados, pasta dos aplicativos, executáveis, TUDO ! De preferência em duas cópias, porque backup é mestre pra não funcionar quando você mais precisa dele.
E não adianta comprar um CDzinho vagabundo na esquina. Ouça: NÃO ECONOMIZE neste ponto ! Os dados que você pode perder são de valores incalculáveis.
E não vale também fazer backup e guardar dentro da própria máquina. Os motivos eu não preciso nem explicar.
Crie uma base de testes
Não faça a migração em plena base oficial (ambiente de produção). Então, simule tudo em um ambiente o mais fiel possível do real. Se for um ERP, Crie um banco de dados de teste, use os executáveis que estão em produção. Assim você terá como corrigir alguns erros que irão ocorrer na sua migração oficial, antes mesmo que ela ocorra, diminuindo assim o tempo em que a empresa ficará sem utilizar o sistema.
Devem ser feitos os casos de teste e plano de testes bem claros. Os Casos de testes devem ser feitos pelo analista e pelo cliente em parceria, pois o cliente tem ciência das funcionalidades e o analista os detalhes do código e da base de dados. O Plano de Teste deve detalhar quais testes serão necessários, quem são os responsáveis envolvidos e suas datas.
Devem ser feitos 4 tipos de testes:
- testes unitários, aonde o programador após a terminar o código faz testes básicos porém consistentes, evitando erros definidos nos requerimentos, de ambiente, de banco de dados e por ai vai;
- testes de sistemas, aonde é feito os testes dos módulos completos;
- testes integrados são os famosos "end-to-end", envolvendo todos os módulos do projeto;
- testes de usuário, aonde somente neste momento o usuário é envolvido para testar as funcionalidades a serem implantadas e também devem ser "end-to-end"
Aceite pelo usuário
O aceite pelo usuário deve ser formal. Após obter o aceite busque o aceite do "sponsor" e certifique para eles que os mesmos são os responsáveis pelo sistema. Somente com este aceite você pode passar para produção.
Passagem para produção
A passagem para produção deve ser feita com muita cautela e se possível em várias ondas, por exemplo, primeiro a criação do banco de dados e carga do dados, segundo rotinas de backup e outras menos essenciais, terceiro módulos on-line. Deve ser separado para o projeto um período de tempo para a estabilização do projeto em produção. Durante este período sempre existe algum stress pois ai estamos trabalhando no mundo real e o cliente precisa naquele momento que o sistema agora em produção esteja funcionando corretamente.
Após estar tudo certo busque o aceite final do projeto com o sponsor e repasse o projeto para o time de manutenção oficialmente, isto é, de forma formal.
Projeto terminado, é a hora de gerar as lições aprendidas e as métricas, ambos coletados em tempo de execução do mesmo. É tempo também das atividades de fechamento de contratos e liberação dos recursos.
Boa sorte e bons projetos!!!
