gp.md

@@ -157,17 +157,6 @@ Além das datas principais de cada sprint, as sprints de desenvolvimento (1, 2,
 | Sprint Retrospective | A Retrospectiva da Sprint é uma oportunidade para o time se inspecionar e criar um plano de melhorias a serem implementadas durante a próxima Sprint. Durante o evento, a equipe discute o que correu bem na Sprint e o que pode ser melhorado na próxima Sprint. Em seguida, em cima do que pode ser melhorado, são levantados Action Items para que todos busquem efetivar essas mudanças. Embora melhorias possam ser implementadas a qualquer momento, a Retrospectiva da Sprint oferece uma oportunidade formal para focar na inspeção e adaptação. | AGES IV | AGES I, II, III, IV | A cada final de Sprint | 1 hora |
 | Tasks Breakdown | Momento em que é realizada a quebra e a documentação no Trello de cada User Story priorizada para a Sprint em tarefas técnicas específicas, mensuráveis, pequenas o suficiente e idealmente paralelizáveis. | AGES III de cada Squad | Integrantes de cada Squad | A cada final de Sprint | 30 minutos |
 
-Ferramentas:
-
-|Ferramenta|Objetivo|Modalidade|Frequência|Participantes|
-|-----|-----|-----|-----|-----|
-|Zoom|Canal para as apresentações para os stakeholders, início e encerramento de sprints, e dailies em dias de aula|Síncrona|Semanal|Orientador, equipe e stakeholders|
-|Discord|Canal para desenvolvimento das atividades rotineiras da equipe|Síncrona|Sempre que necessário|Orientador e equipe|
-|WhatsApp|Dúvidas e informações rápidas fora do horário de aula ou com colegas que não estão disponíveis no Discord, e comunicação assíncrona dos GP's com os stakeholders|Assíncrona|Sempre que necessário|Orientador, equipe e stakeholders|
-|Trello|Organização das tarefas da equipe na forma de Kanban para acompanhamento do progresso|Assíncrona|Sempre que necessário|Orientador e equipe |
-|Easy Retro|Ferramenta utilizada para conduzir as retrospectivas da equipe|Síncrona|Uma a cada sprint|Orientador e equipe |
-|Figma|Definição e documentação precisa dos elementos de UI e UX da aplicação|Assíncrona|Sempre que necessário|Orientador e equipe|
-
 
 <div id="matriz_de_responsabilidade"/>
 
@@ -220,11 +209,10 @@ Significado das letras:
 
 | **Risco** | **Probabilidade** | **Impacto** | **Severidade** | **Estratégia** | **Ações** |
 |:---------:|:-----------------:|:-----------:|:--------------:|:--------------:|-----------|
-| Alterações de escopo | 4 | 5 | 20 | Mitigar | Definir escopo no início do projeto e balancear aceitando apenas mudanças pequenas (que não exijam retrabalho) ao decorrer do projeto. |
-| Falta de engajamento de membros | 4 | 5 | 20 | Mitigar | Manter comunicação ativa e conversas direcionadas quando isso acontecer. E caso ocorra e esteja impactando demais membros do time, reorganizar tarefas da forma necessária. |
-| Falta de entrega de User Stories planejadas | 4 | 4 | 16 | Mitigar | 1. Acompanhar desenvolvimento do time; caso um possível atraso seja identificado, auxiliar no que for necessário.  
-2\. Definir tempo de integração de tarefas, para que seja possível desenvolver algumas tarefas pendentes. |
-| Problemas inesperados na demostração para o cliente | 4 | 5 | 20 | Eliminar | Realizar testes funcionais para cada contribuição de código e antes da entrega com a versão final da aplicação. |
-| Falta de presença do stakeholder | 2 | 5 | 10 | Transferir | Mandar lembretes com 6h de antecedência e manter comunicação aberta e disponível com o stakeholder, assim fica a cargo do mesmo nos avisar com atencedência em caso de falta necessária |
-| Entrega de User Stories planejadas antes do fim da sprint | 3 | 5 | 15 | Melhorar | Tendo entregue o que foi planejado, analisar capacidade para mais USs dentro do nosso planejamento da Sprint |
-| Falta de créditos para AWS da AGES | 4 | 4 | 16 | Transferir | Transferir essa necessidade para o stakeholder, caso queira as entregas em homologação, disponibilizar conta AWS para que seja utilizada na AGES durante o andmento do projeto |
+| Alterações no escopo do projeto | 4 | 4 | 16 | Mitigar | Definir corretamente o escopo no início do projeto e conferir o que foi levantado com os stakeholders. Além disso, balancear aceitando no decorrer do projeto somente mudanças pequenas que não exijam retrabalho. |
+| Falta de engajamento dos membros do time | 3 | 7 | 21 | Mitigar | Manter tracking do desenvolvimento das atividades no Trello e fazer checkpoints periódicos com as squads. Caso ocorra e impacte o resto do time e as entregas, conversas diretamente com o membro do time e reorganizar as atividades conforme necessário. |
+| Não entregar as User Stories do sprint backlog | 3 | 6 | 18 | Mitigar | Manter tracking do desenvolvimento das atividades no Trello, fazer checkpoints periódicos com as squads e sempre garantir que não há algum impedimento com qualquer membro. Além disso, sempre deixar claro o deadline de entrega das USs, que deve ser, por precaução, pelo menos 2 dias antes da sprint delivery. |
+| Problemas inesperados no sprint delivery | 3 | 7 | 21 | Eliminar | Efetuar testes funcionais no código e na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência do sprint delivery. |
+| Ausência do stakeholder no sprint delivery | 2 | 8 | 18 | Transferir | Mandar lembretes com 6h de antecedência e manter comunicação aberta e disponível com o stakeholder, assim fica a cargo do mesmo nos avisar com antecedência em caso de falta necessária |
+| Impossibilidade de homologação na AWS | 8 | 2 | 16 | Transferir | Transferir a homologação para alguma plataforma alternativa, como Heroku, e identificar por que não foi possível utilizar a AWS e solucionar o problema. |
+| Falta de créditos da AGES para homologação na AWS | 4 | 4 | 16 | Transferir | Transferir a homologação para alguma plataforma alternativa, como Heroku, caso o stakeholder não queira disponibilizar uma conta na AWS para homologação. |
\ No newline at end of file
\ No newline at end of file