Post mortem
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 24/09/2017 | 1.0 | Primeira versão completa do documento | Rodrigo Oliveira Campos |
| 10/12/2017 | 2.0 | Segunda versão completa do documento | Cleber, Caio, Rodrigo, Pablo |
Este documento tem o intuito de relatar os acontecimentos do projeto, bem como os problemas enfrentados e ressaltando principalmente as tomadas de decisão acerca dos riscos que foram se formando no decorrer das atividades.
Os acontecimentos do projeto foram divididos em duas partes principais, salientando os maiores problemas ocorridos.
Os clientes de cada grupo da disciplina foram definidos na segunda semana de aula, na terça-feira (15/08/2017). No dia seguinte tivemos nossa primeira reunião com o grupo de MDS e enviamos um e-mail nos apresentando para o cliente e verificando a disponibilidade para uma reunião. Apenas na sexta-feira (18/08/2017), o cliente nos respondeu e começamos a nos comunicar pelo telegram, onde marcamos a primeira reunião para terça-feira (22/08/2017) da semana seguinte. Foi nesta sexta-feira também que fizemos nosso primeiro treinamento, com o intuito de não ficarmos ociosos, sobre MVC e Orientação a Objetos.
Duas semanas se passaram e ainda não sabíamos do que se tratava o projeto, a única coisa que foi nos dito era que tinha algo a ver com a Lei Rouanet. Nos reunimos com o cliente no dia marcado e conversamos por aproximadamente duas horas, onde este não demonstrou ter nenhuma necessidade específica e uma forte resistência a metodologia tradicional utilizada na primeira etapa da disciplina. O cliente nos mostrou algumas das iniciativas que o MinC possuía (Mapas Culturais e VERSALIC) e nos disse para pensar em uma proposta de projeto, que utilizasse dados de alguma dessas plataformas, e apresentássemos na próxima terça-feira (29/08/2017).
Passamos o resto da segunda semana de aula pensando em um projeto que fosse aceitável, o que não foi uma tarefa fácil, tendo em vista que muitas das coisas que pensamos já existiam e foram criadas pelo próprio MinC. Na quarta (23/08/2017) demos um treinamento de GIT para MDS e na sexta (25/08/2017) um treinamento de RUP. Ao fim da semana tínhamos definido uma proposta de projeto que utilizava os dados do VERSALIC para gerar alguns indicadores sobre a a Lei Rouanet.
Já estávamos na terceira semana de aula e ainda não tínhamos um escopo definido para o projeto, a reunião de terça-feira (29/08/2017) era crucial, tínhamos que definir o projeto naquela reunião, se não os riscos se tornariam muito altos. O cliente demonstrou pouco interesse em nossa proposta e tentou nos direcionar para a utilização da plataforma Mapas Culturais, mas sem nos dizer o que ele esperava do projeto e mais uma vez teríamos que pensar em mais uma proposta, perdendo mais uma semana. Foi então que conversamos com a professora sobre a situação e ela então nos disse que o cliente estava se tornando um risco muito grande e que deveríamos definir um escopo e caso o cliente não aceitasse, devíamos nos afastar dele.
Nesse processo, acabamos utilizamos 3 semanas de projeto na definição de escopo, estávamos bastante atrasados, porque além de executar as atividades de gerência, tivemos que pensar em uma proposta de projeto não trivial e sem pouco ou quase nenhum auxílio por parte do cliente.
Já estávamos bastante atrasados no cronograma, já tinham se passado 3 semanas e só tínhamos uma visão geral do que seria o projeto. Nossa fase de elaboração foi bastante conturbada, a equipe ainda não tinha uma visão alinhada sobre o projeto, diversas reuniões foram feitas e ainda sim havia dificuldade de consenso em relação ao escopo.
Por conta dos atrasos na definição de escopo, demoramos a definir as tecnologias utilizadas e por consequência alguns treinamentos atrasaram também. Isto fez com que tivéssemos que definir tudo de maneira rápida, sem muito tempo para pensar nas possibilidades. Além disso, vale ressaltar que nossa equipe possuía horários bastante conflitantes, sendo possível uma reunião presencial, com todos os membros somente as quartas-feiras.
Por Josué:
Esse sentimento de que sempre estamos atrasados, que a execução do processo está constantemente fora do cronograma, de que tudo ta pegando fogo e até o extintor que você usa pra apagar o incêndio também está em chamas, esse é o sentimento que compartilho até o momento, espero que até a execução final do projeto eu não esteja em chamas.
Fomos bastante prejudicados pela definição de escopo conturbada, porém devíamos ter gerenciado melhor os riscos das negociações com o cliente, tentado algumas abordagens diferentes em alguns aspectos de escopo e metodologia, sendo menos flexiveis e mais incisivos com os requisitos, pois este talvez tenha sido nosso maior risco encontrado que acabou atrasando a baseline de concepção. A equipe de gerência tentou ao máximo passar confiança para a equipe de desenvolvimento, sempre mantendo a calma e buscando sanar dúvidas, porém houve uma certa onda de desânimo generalizado na equipe por conta dos problemas que ocorreram durante a fase inicial do projeto, que provavelmente afetou a postura de MDS e os tornou mais dependentes e reativos nas próximas atividades do projeto.
Neste relato teremos uma descrição de acontecimentos marcantes sobre o projeto e lições aprendidas durante o desenvolvimento.
Nossa plataforma se transformou em um produto com o qual não imaginávamos. O escopo instável se transformava a cada sprint onde conhecíamos melhor os dados do Mapas Culturais, as necessidades do cliente e os micro serviços com os quais começamos a trabalhar.
Apesar de todo o trabalho e luta contra os containeres e o docker inicialmente no projeto, estes foram muito inovadores para a equipe, a curva de aprendizado foi dura e ao mesmo tempo valiosa, onde a arquitetura do projeto se complexificou em mais módulos, porém cada um mais simples, executando micro serviços que complementam as funcionalidades da aplicação.
Cada decisão arquitetural tinha um custo enorme para a equipe, porém, ao solucionar a integração inicial, a plataforma ficava estável, sendo totalmente configurável com um comando, algo que foi impressionante para os futuros deploys que realizamos.
O Metabase provavelmente foi a maior mudança arquitetural do projeto, como não era previsto no planejamento inicial a implementação dele foi dificultada por outras partes do projeto, como o MongoDB e trouxe diversas mudanças no código que já estava feito e testado, mas que foram superadas pela equipe. Estes problemas foram superados pois os benefícios da utilização do mesmo trouxeram uma maior flexibilidade à aplicação tornando possível recriar os gráficos utilizando os dados salvos no banco com apenas alguns cliques, evitando diversas linhas de código e impedimento de uma futura evolução da plataforma.
Ao longo da evolução do projeto com o metabase vimos que usar o MongoDB não foi uma solução eficiente, pois houveram mudanças na arquitetura que fizeram o banco de dados não relacional uma solução ruim, pois mudou totalmente a ideia inicial de salvar apenas os indicadores no banco .
Outra dificuldade que o MongoDB trouxe foi a relação dele com o metabase, que é uma ferramenta nova onde não há ainda um suporte grande para bancos não relacionais, dificultando a manipulação dos dados utilizando instruções manualmente e criação dos gráficos sem a utilização da interface visual para queries.
O projeto começou com um rumo incerto, não tínhamos um escopo definido pelo cliente e estávamos bem perdidos quanto ao decorrer do projeto. Na fase ágil da disciplina, a situação do escopo não mudou muito, porém nosso cliente foi bem prestativo e mantemos um bom contato. A cada sprint conseguimos definir um bom escopo para a sprint e assim íamos incrementando o projeto. Apesar deste modo de operação ter funcionado, tivemos o ponto negativo de não ter uma visão a longo prazo do projeto, o que desencadeou outros pontos negativos, como não conseguir mensurar o valor entregue do projeto em cada sprint e tomar algumas decisões ruins no início do projeto.
Passamos por vários problemas durante a execução do projeto, lidamos com uma enxurrada de riscos, mas foi um grande aprendizado, tanto na parte técnica com deploy contínuo, micro serviços, tecnologias muito novas, quanto na parte de gerência lidando com riscos e tentando sempre manter a produtividade da equipe e a qualidade do produto.
Futebol na quarta feira >>> MDS
Apesar de todas as mudanças sofridas ao longo do semestre o projeto foi concluído de forma satisfatória, onde nosso maior produto é a arquitetura orientada a micro serviços auto contidos para o cliente.
A solução apresenta indicadores interessantes e as atualizações recentes das bases de dados do Mapas Culturais. E ao mesmo tempo é modular suficiente para se adaptar as ferramentas em produção do cliente de forma satisfatória.
- Visão Geral
- Políticas do Repositório
- Licença
- Copyleft
- Notas sobre a Release
- Contatos
- Atas de Reunião
- Apresentação R1
- Acesse a plataforma
- Link Alternativo
- Post mortem