Relatório de riscos
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 25/09/2017 | 1.0 | Primeira versão do documento | Hugo Neves de Carvalho |
| 26/09/2017 | 1.1 | Adicionando alguns riscos | Rodrigo Oliveira |
| 26/09/2017 | 1.2 | Adicionando todos os riscos restantes | Josué Nascimento da Silva |
| 27/09/2017 | 1.3 | Adicionando atributos dos riscos | Josué Nascimento da Silva |
| 28/09/2017 | 1.3 | Adicionando riscos não planejados | Josué Nascimento da Silva |
Este relatório tem como objetivo explicitar a aplicação do planejamento nos riscos ocorridos durante o projeto. Para maior clareza serão utilizados os IDs estabelecidos no Plano de Gerenciamento de Riscos.
Categoria na EAR: Cliente
Impacto: Alto
Descrição do risco: Neste caso ocorreu atraso na definição do escopo por parte do cliente. Isso ocorreu devido a indecisão e o choque entre os tipos de metodologia do cliente(Ágil) e a disciplina (RUP), ou seja, não havia nenhum interesse, por parte do cliente, nas documentações produzidas. Esse segundo problema surgiu por falta de conhecimento em como a disciplina é organizada. Todo essa situação gerou atraso no cronograma e principalmente o levantamento ,definição do escopo e validação dos requisitos como descritos aqui
Resposta: Mitigar
Ação adotada: Como no planejamento o impacto e prioridade para este risco são altas, a decisão foi de explicitar para o cliente mais detalhes sobre a disciplina e as necessidades da equipe. Neste novo acordo foi decidido por uma comunicação mais tradicional e menos ágil como estava acontecendo, para cumprirmos as exigências da disciplina e manter o valor agregado ao cliente.
Resultado: Essa nova abordagem com o cliente e os requisitos permitiu que a equipe amadurecesse tecnicamente para enfrentar a adaptabilidade ágil e manter-se dentro da metodologia proposta da disciplina.
Categoria na EAR: Tecnologia
Impacto: Muito Alto
Descrição do risco: A equipe de desenvolvimento apresentar deficiência técnica quanto ao uso da tecnologia adotada.
Resposta: Mitigar
Ação Adotada: A equipe de gerência manteve-se sempre proximo da da equipe de desenvolvimento. Realizando dojos de linguagem, Treinamentos e pareamentos entre GPP e MDS para melhorar a produtividade e para que a equipe de desenvolvimento alcançar um melhor desempenho. os treinamentos oferecidos podem ser vistos aqui
Resultados: As ações tomadas ajudaram mds a ter um melhor desempenho, porém acabou gerando certa dependência da equipe de desenvolvimento com GPP.
Categoria na EAR: Recursos
Impacto: Muito Alto
Descrição do risco: Membros da equipe de GPP/MDS ficarem ausentes por muito tempo sem relatar a equipe quando estarão disponíveis para a realização do projeto, gerando sobrecarga de trabalho aos demais membros restantes
Resposta: Prevenir
Ação Adotada: A equipe de GPP primeiramente buscou manter-se coesa para que os membros não se tornassem ausentes e sim integrados. Quanto a MDS, a equipe de GPP manteve reuniões periódicas e quando necessário individuais, para sempre ter um feedback da produtividade de cada membro da equipe de MDS. Os membros que se ausentaram, foram feitas reuniões não oficiais e muitas vezes não presenciais para poder entender o motivo da ausência e tentar reintegrar o membro ao desenvolvimento. Alguns membros de acordo com suas grades horárias obtidas no planejamento de recursos humanos, foram monitorados com maior foco durante as reuniões e alinhamentos da equipe pela falta de horários disponíveis de trabalho.
Resultados: A equipe de GPP/MDS no geral se manteve coesa e mantiveram-se próximos. Existindo apenas um membro de MDS que se manteve ausente apesar das tentativas de reintegração, como se esperava através das poucas disponibilidades de horário e motivação, se apresentando apenas algumas vezes e contribuindo muito pouco pro desenvolvimento do projeto. Uma surpresa encontrada para nosso planejamento de disponibilidades foi o membro com a menor disponibilidade de horários se tornar um dos mais produtivos da equipe de desenvolvimento, contrariando nossas expectativas.
Categoria na EAR: Comunicação
Impacto: Médio
Descrição do risco: A existencia de uma má comunicação entre a equipe de gerência e a equipe de desenvolvimento pode resultar em falta de alinhamento quanto ao projeto e também resultar em atrasos no projeto.
Resposta: Prevenir
Ação Adotada: A equipe de GPP optou pelo uso de ferramentas que auxiliassem na realização de uma boa comunicação levando em consideração as necessidades da equipe. A gerência de comunicação pode ser encontrada aqui
Categoria na EAR: Requisitos
Impacto: Alto
Descrição do risco: Caso o durante a execução do projeto o escopo não se estabilize. impossibilitando uma baseline bem definida para elaboração do projeto, dificultando o entendimento da equipe de desenvolvimento dos requisitos da aplicação.
Resposta: Mitigar
Ação Adotada: Buscamos adotar uma abordagem modular na arquitetura da aplicação, que pudesse se adaptar a novos requisitos e torna-se as funcionalidades coesas e com baixo acoplamento. Para visualizar a descrição arquitetural clique aqui
Resultado: Um projeto modular com baixo acoplamento e alta coesão.
Categoria na EAR: Desempenho e confiabilidade
Impacto: Médio
Descrição do risco: A arquitetura do software for mal desenvolvida
Resposta: Mitigar
Ação Adotada: Foram realizados treinamentos de arquitetura, Orientação à Objetos e de linguagem
Resultado: A arquitetura foi bem implementada pela equipe de desenvolvimento sem muita interferência de GPP.
Categoria na EAR: Segurança
Impacto: Médio
Descrição do risco: Houver perda de equipamentos da equipe
Resposta: Aceitar
Ação Adotada: Marcar reuniões durante o dia na faculdade, e após as 18h apenas através de Hangouts.
Resultado: Ninguém perdeu nenhum equipamento.
Categoria na EAR: Estimativas
Impacto: Médio
Descrição do risco: O mau levantamento de estimativas pode levar a definições de prazos errôneas e com baixa confiabilidade.
Resposta: Mitigar
Ação Adotada: A partir do momento em que foi detectada baixa confiabilidade das estimativas, nossa equipe utilizou uma técnica que chamamos de "estimativa das estimativas". Essa técnica consiste em cada membro da equipe de gerência fazer sua própria estimativa para cada atividade, fazemos uma média com as estimativas dos membros e discutimos se o valor final é valido ou não.
Categoria na EAR: Qualidade
Descrição: O produto de software ter uma baixa qualidade
Resposta: Mitigar
Ação Adotada: A equipe de gerência tomou as seguintes ações para a entrega de um produto de qualidade configuração de ambiente, monitoramento de desenvolvimento continuo das métricas,folha de estilo ,definição de refatoração de código, politicas de repositorio
Resultado: Produto que respeita todas as especificações de qualidade citadas acima
Categoria na EAR: Tecnologia
Impacto: Médio
Descrição do risco: Por conta do tema do projeto ser focado em Data Science, houve certa dificuldade no desenvolvimento das features do software.
Resposta: Mitigar
Ação Adotada: A equipe de gerência percebeu dificuldades da equipe de desenvolvimento para compreender o escopo e como desenvolver a solução proposta, foi então que realizamos algumas reuniões presenciais, para esclarecimento e desenvolvimento, aos sábados com ambas equipes juntas.
Resultados: As reuniões foram produtivas e serviu para amadurecer, em parte, a equipe der desenvolvimento.
Categoria na EAR: Tecnologia
Impacto: Médio
Descrição do risco: Alguns bugs, na API que estamos utilizando, foram encontrados e provocaram um pequeno atraso no desenvolvimento.
Resposta: Mitigar
Ação Adotada: Entramos em contato com a equipe que desenvolveu e mantém a API, para informar os bugs e se possível consertá-los.
Resultados: Os bugs não foram resolvidos, mas a equipe da API nos deu uma solução momentânea.
Categoria na EAR: Requisitos
Impacto: Médio
Resposta: Mitigar
Descrição do risco: Por conta da abordagem que o cliente utilizou, surgiu um atraso na definição de um escopo.
Ação Adotada: Fizemos 3 reuniões de brainstorming e 1 de consolidação de ideias, para elaborar uma proposta de projeto, porém com a indecisão do cliente, fechamos o escopo com o que já tínhamos e passamos para outra fase do processo.
Resultados: Faltou um alinhamento sobre a visão do projeto em alguns momentos pela equipe e o escopo do projeto ficou meio genérico.
Categoria na EAR: Tecnologia
Impacto: Alto
Resposta: Prevenir
Descrição do risco: Problemas de conflitos em versões diferentes de sistemas operacionais e das ferramentas utilizadas.
Ação Adotada: Utilizar a ferramenta Docker para padronizar os ambientes de desenvolvimento e evitar problemas de versionamento.
Resultados: Houveram certos problemas com a utilização do MongoDB com o Docker, onde não era possível o Django se conectar ao banco de dados, mas após dois dias, a equipe conseguiu resolver o problema e o restante do desenvolvimento foi executado sem mais problemas de ambiente.
Os riscos inesperados, foram os riscos que estavam fora do planejamento inicial do projeto, e foram identificados ao longo da execução do projeto
1.Risco: Dependência de MDS em relação a GPP para produzir o código: As ações tomada com treinamentos para melhor capacitação de MDS, gerou uma dependência em que MDS onde a produtividade só era maior quando havia alguém de GPP próximo, em muitos momentos não ouve produção de código devido a impossibilidade de GPP está presente, com isso existiu atraso no desenvolvimento do código.
2.Risco: Dificuldade da configuração do Docker com o mongoDB: A configuração do container para uso do mongoDB atrasou bastante o desenvolvimento, pois o método que efetuava a conexão não especificava qual era o host, com isso a conexão chamava por padrão o 'localhost', sendo que deveria invocar como host o container 'mongo'. A equipe de GPP e a equipe de MDS demoram muito para chegar a uma solução, resultando no atraso do desenvolvimento.
3.Risco: Problema na implementação dos teste: A principio foi definido o uso do TestCase para realizar os teste unitários, porem não foi possível integrar os uso dele com o uso do mongoDB que foi adotado para a implementação do projeto, levou-se um dia para resolver esse problema com os teste, o que resultou em atraso na implementação do projeto. TestCase
- 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