Gerência
Acesso rápido
- Termo de Abertura do Projeto
- Estrutura Analítica do Projeto (EAP)
- User Story
- Cronograma
- Matriz de responsabilidade
- Sprints
Matriz de responsabilidades
Matriz de responsabilidade no Google Sheets
Sprint 0
| 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 |
| 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 |
| 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 |
Sprint 1,2,3,4
| Atividade |
AGES I |
AGES II |
AGES III |
AGES IV |
| Alimentar a wiki |
R |
R |
R |
R |
| 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 |
| 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 |
| 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 |
Max Franke |
| 4 |
A Definir |
Plano de Comunicação
| Evento |
Descrição |
Responsável |
Envolvidos |
Frequência |
Duração |
| Kickoff |
A reunião de kickoff serve para convergir os interesses do Cliente e do time. Nela tiramos as dúvidas e alinhamos o que será desenvolvido no projeto com o auxílio do cliente. |
Cliente |
AGES I, II, III, IV e Cliente |
Uma vez |
1 hora e 30 minutos |
| Daily |
Atualização de cada integrante do time sobre o que foi feito desde o último encontro, o que será feito, se há algum problema ou algo a ser comentado. |
Ages IV |
AGES I, II, III, IV |
Seg e Quarta, 17:30 |
15 minutos |
| Sprint Review |
Avalia-se o que foi feito e desenvolvido durante a Sprint |
Ages IV |
AGES I, II, III, IV e Cliente. |
A cada final de sprint |
1 hora |
| Sprint Planning |
Avalia-se o que será realizado durante a Sprint, priorizando os itens do Backlog para aquela Sprint. |
Ages IV |
AGES I, II, III, IV e Cliente |
A cada final de Sprint |
30 minutos |
| Sprint Retrospective |
A retrospectiva trata-se de uma oportunidade para o time avaliar fraquezas e fortalezas a serem implementadas para próxima Sprint. Ocorre a discussão do que foi bom/ruim durante a Sprint e é o jeito de formalizar o que foi feito de bom/ruim durante aquele aquele período de tempo. |
Ages IV |
AGES I, II, III, IV |
A cada final de Sprint. |
1 hora e 30 minutos |
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. |
matheus.moraes