| ... | ... | @@ -155,16 +155,24 @@ Tendo em vista que na primeira sprint do projeto temos atividades diferentes que |
|
|
|
|
|
|
|
## Plano de Comunicação
|
|
|
|
|
|
|
|
| **Evento** | **Descrição** | **Responsável** | **Envolvidos** | **Frequência** | **Duração** |
|
|
|
|
|**Evento**|**Descrição**| **Responsável** |**Envolvidos**|**Frequência**|**Duração**|
|
|
|
|
| :----------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-------------: | :------------------------------: | :---------------------------------------------------------------------------------: | :-------------------------------------: |
|
|
|
|
| Kick Off (Exemplo) | Primeiro encontro entre o time e os stakeholders do projeto. Nesse encontro são apresentados os principais itens do projeto e a ideia geral. Também são realizados questionamentos sobre o que foi apresentado, com a finalidade de ajudar nas definições dos requisitos do projeto em conjunto com o cliente. (Exemplo) | Cliente(s) (Exemplo) | AGES I, II, III, IV e Cliente(s) (Exemplo) | Uma vez (início do projeto) (Exemplo) | 1 hora - 1 hora e 30 minutos (Exemplo) |
|
|
|
|
| TBD... | TBD... | TBD... | TBD... | TBD... | TBD... |
|
|
|
|
| Kickoff | A reunião de Kickoff é a primeira reunião entre o time e os Stakeholders. Nela é apresentada a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitando um levantamento inicial dos requisitos do projeto por parte da equipe, com o auxílio do cliente, que detém o conhecimento sobre o produto a ser desenvolvido. | AGES IV e Cliente | AGES I, II, III, IV e Cliente | Uma vez no início do semestre | 1 hora e 30 minutos |
|
|
|
|
| Daily | Cada integrante do time atualiza os demais sobre o que fez desde o último encontro síncrono, o que pretende fazer em seguida e se tem impedimentos para que possam ser solucionados. As dailies são registradas pelos AGES IV | AGES IV | AGES I, II, III, IV | Terças-feiras via Discord e Sextas-feiras às 19:15 | Máximo 20 minutos |
|
|
|
|
| Sprint Review | Momento de apresentar para o Cliente o que foi desenvolvido durante a Sprint coletando validações e feedback dos Stakeholders para cada atividade acordada.| AGES IV | AGES I, II, III, IV e Cliente | No final de cada sprint | 1 hora |
|
|
|
|
| Sprint Planning | Decisão, junto ao cliente, das tarefas que serão realizadas durante a sprint seguinte. | AGES IV | AGES I, II, III, IV e Cliente | No final de cada sprint | 30 minutos |
|
|
|
|
| Retrospectiva da Sprint | Momento onde o time reflete sobre a sprint anterior, levantando os pontos bons, ruin e melhorias a serem feitas. | AGES IV | AGES I, II, III, IV | Após a Sprint Planning | 30 minutos |
|
|
|
|
| Planning Poker | Momento em que o time atribui um nível de complexidade para cada tarefa da Sprint e comenta como pode ser feita. | AGES IV | AGES I, II, III, IV | Após retrospectiva | 30 minutos |
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Plano de Riscos
|
|
|
|
|
|
|
|
| Risco | Prevenção | Contingência | Estratégia |
|
|
|
|
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ---------- |
|
|
|
|
| Atingir limite de uso gratuito da AWS (Exemplo) | Utilizar servidores apenas para validação, desligando-os quando não utilizados (Exemplo) | Alterar ambiente para outra conta de usuário (Exemplo) | Transferir (Exemplo) |
|
|
|
|
| TBD... | TBD... | TBD... | TBD... | |
|
|
\ No newline at end of file |
|
|
|
| **Risco** | **Probabilidade** | **Impacto** | **Severidade** | **Estratégia** | **Ações** |
|
|
|
|
|:---------:|:-----------------:|:-----------:|:--------------:|:--------------:|-----------|
|
|
|
|
| Alterações no escopo do projeto | 6 | 5 | 30 | Mitigar | Evitar grandes mudanças no escopo asó a definição inicial, aceitando somente mudanças que não necessitem de muito retrabalho. |
|
|
|
|
| Falta de engajamento dos membros do time | 7 | 8 | 56 | Mitigar | Acompanhar o desenvolvimento das tarefas no Trello. Fazer reuniões periodicas (dailies) para saber sobre o progresso do desenvolvimento. Caso haja impacto no time, conversar com os membros do time e replanejar as tarefas caso necessário. |
|
|
|
|
| Não entregar as tarefas da Sprint | 5 | 6 | 30 | Mitigar | Acompanhar o desenvolvimento das atividades no Trello e realizar reuniões periódicas com o time para saber sobre o progresso do desenvolvimento, ressaltando o tempo limite da sprint. |
|
|
|
|
| Problemas inesperados na entrega | 3 | 8 | 24 | Eliminar | Testar a aplicação na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência da entrega da sprint. |
|
|
|
|
| Ausência do cliente no sprint delivery | 1 | 8 | 8 | Transferir | Relembrar o cliente da entrega da sprint. |
|
|
|
|
| Falta de créditos da AGES para homologação na AWS | 2 | 4 | 16 | Transferir | Realizar a homologação em uma plataforma alterativa, como MS Azure. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente. |
|
|
|
|
| Falta de conhecimento nas tecnologias utilizadas | 6 | 6 | 36 | Mitigar | Recomendar documentações e tutoriais sobre as tecnologias utilizadas para os membros do time. Desenvolver utilizando _pair programming_ para compartilhamento de conhecimento. | |
|
|
\ No newline at end of file |
