| ... | ... | @@ -42,18 +42,37 @@ |
|
|
|
| Atividade | AGES I | AGES II | AGES III | AGES IV |
|
|
|
|
| --------- | ------ | ------- | -------- | ------- |
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
| Definir ferramenta de mockups | C | R | A | A |
|
|
|
|
| Desenvolver mockups | C | R/A | C | A |
|
|
|
|
| Definir arquitetura | I | I | R/A | C/A |
|
|
|
|
| Definir tecnologias (front/back) | C | C | R/A | A |
|
|
|
|
| Criar projeto inicial (front/back) | I | I | R/A | A |
|
|
|
|
| Definir estratégia de Verificação e Validação | I | C | R/A | C/A |
|
|
|
|
| Definir squads | C | R | A | A |
|
|
|
|
| Definir marcos da sprint | I | I | C | R/A |
|
|
|
|
| Quebra de tasks | C | C | R | R/A |
|
|
|
|
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
|
|
|
|
| Criar User Stories | C | C | C | R/A |
|
|
|
|
| Realizar estudos dirigidos | R | R | R | R |
|
|
|
|
| Definir plano de comunicações | I | I | I | R/A |
|
|
|
|
| Desenvolvimento | R | R | R/A | C/A |
|
|
|
|
| Code review| C | C | R/A | C |
|
|
|
|
| Deploy da aplicação | I | I | R | A |
|
|
|
|
| Definir organização do time | I | I | C | R/A |
|
|
|
|
| Documentação de requisitos | R/A | C | C | A |
|
|
|
|
| Definir o git workflow | C | C | R | A |
|
|
|
|
| Modelar o BD (conceitual/lógico) | I | R/A | R/A | A |
|
|
|
|
| Apresentar no dia 23/08 | C | C | C | R | |
|
|
\ No newline at end of file |
|
|
|
| Apresentação da review | C | C | C | R |
|
|
|
|
|
|
|
|
**Apresentações ao Stakeholder**
|
|
|
|
|
|
|
|
|Sprint | Pessoa (R)|
|
|
|
|
| --------- | ------ |
|
|
|
|
| 0 | Max Franke |
|
|
|
|
| 1 | Lucas Schell |
|
|
|
|
| 2 | Frederico Thofehrn |
|
|
|
|
| 3 | Ramiro |
|
|
|
|
| 4 | A Definir |
|
|
|
|
|
|
|
|
## Plano de riscos
|
|
|
|
|
|
|
|
| Risco | Probabilidade | Impacto | Severidade | Estratégia | Ações |
|
|
|
|
| --------- | ------ | ------- | -------- | ------- | ------- |
|
|
|
|
| Falta de engajamento de membros | 4 | 5 | 20 | Mitigar | Avaliar com colegas e comunicar quando isso acontecer. Caso esteja muito difícil de lidar com esse risco, reorganizar os times. |
|
|
|
|
| Problemas inesperados na demostração para o cliente | 4 | 5 | 20 | Eliminar | Realizar testes prévios e validar na noite anterior à apresentação |
|
|
|
|
| Alterações de escopo | 4 | 5 | 20 | Mitigar | Definir no inicio do projeto e validar qualquer tipo de mudança com o time |
|
|
|
|
| Falta de presença do stakeholder | 2 | 5 | 10 | Transferir | Validar na manhã da apresentação com o cliente. Manter comunicação presente. |
|
|
|
|
| Falta de entrega de User Stories planejadas | 4 | 4 | 16 | Mitigar | Definir tempo de desenvolvimento das tarefas. Acompanhar desenvolvimento do time. Ajudar no que for necessário. |
|
|
|
|
|
|
|
|
|
|
|
|
|
