Lições do Projeto - Conservação dos Campi

De DTI Wiki

COMO NÃO FAZER
1) Readequação do projeto após a fase de análise: O projeto foi refeito após a fase de análise já estar em andamento. Por este motivo a maioria dos procedimentos sofreram adequações - tanto os que estavam em andamento quanto os que ainda estavam no projeto.

2) Projeto muito extenso: Por ser extenso, o projeto foi dividido em módulos. Porém, em função de outras prioridades, o mesmo teve inúmeras paradas e retornos. Dessa forma, existe um tempo perdido, que é o tempo de retorno ao projeto: muitas ideias são esquecidas/perdidas. Em projetos com muitos módulos ocorre, também, a dificuldade da manutenção dos sistemas, pois muitos objetos estão em produção (módulo I, por exemplo) e em alteração (módulo II). É preciso muita atenção caso precise de alguma correção no módulo que está em produção.

3) Alteração dos Envolvidos: Muitas pessoas envolvidas no projeto abandonaram o mesmo: ou por desligamento da Instituição ou devido ao envolvimento em outros projetos. Isto prejudicou o andamento projeto em questão.

4) Testes - falta de padronização: A padronização básica não foi observada durante o desenvolvimento, tanto a parte visual quanto a parte funcional. Por este motivo, o sistema teve inúmeros "RE-testes". É preciso fazer uso das ferramentas disponíveis para consulta dos padrões e, quando necessário, verificar pessoalmente com as pessoas responsáveis qual é a maneira mais indicada para atender o requisito proposto. A criação é livre, desde que esteja dentro dos padrões.

5) Base de Testes: É preciso que os dados da base de testes sejam mais próximos da realidade, pois o objetivo é fazer testes efetivos do produto.

6) Comprometimento com o produto disponibilizado: Embora este item tenha sido comentado neste projeto, entende-se que o mesmo serve para os sistemas em geral. É preciso colocar-se na posição do usuário e avaliar se o que foi implementado está prático e funcional.

7) Treinamento Interno: Percebeu-se que o treinamento interno não foi produtivo. Há falta de interesse dos participantes. É preciso rever a questão dos treinamentos que são repassados aos usuários, pois como há pouco envolvimento interno, acredita-se que o usuário está recebendo um treinamento muito superficial.

COMO FAZER
1) Acompanhamento diário: No início, houve acompanhamento diário entre os envolvidos no projeto. Isto agiliza o desenvolvimento pois questões simples são resolvidas diariamente.

2) Treinamento Externo - com usuários: Foi bem produtivo (foi explicado o funcionamento geral e após após aplicado o treinamento do sistema. Tentou-se contornar o fato de que o usuário solicitante saiu da UPF e não usará o sistema. Solicitou-se aos novos, que assumiram o setor, a utilização do sistema da forma como foi projetado e desenvolvido. Sugeriu-se fazer uma avaliação do sistema após 1 mês de uso. Contudo, qualquer alteração necessária deverá passar pela fila de solicitações.

3) Procedimentos Oracle menos complexos: Comentou-se quanto a forma ideal do uso dos objetos Oracle: objetos mais dinâmicos, objetos mais re-utilizáveis, PKGs menores - definidas conforme o uso e não conforme o "assunto".

4) Testes ágeis: Foi feito uma bateria de testes de forma ágil, onde o desenvolvedor acompanhou os testes do Analista de Testes. Os problemas encontrados não foram relatados de forma textual, somente apontados ao desenvolvedor durante os testes. Após houve a correção dos problemas pelo desenvolvedor e novos testes foram realizados. Concluiu-se que a documentação dos testes é muito demorada e que isso possa estar causando demora no processo de testes. É preciso adaptar esta etapa dos projetos.

5) Uso de novos recursos: Apesar dos problemas relatados, foram utilizados novos recursos e o produto final ficou muito bom.