Skip to content

GitLab

gerencia · Changes

Page history
refatorando e adicionando coisas authored by Douglas Paz's avatar Douglas Paz
Hide whitespace changes
Inline Side-by-side
gerencia.md
View page @ 59f9c3c2
| [Home](home) | [Escopo](escopo) | [Arquitetura](arquitetura) | [Configuração](configuracao) | [Mockups](design_mockups) | [BD](banco_dados) | [Instalação](instalação) | [**Gerência**](gerencia) | [Qualidade](qualidade) | [Processo](processo) | [Retro](retro) | [Estudos dirigidos](estudos)
| :----------: | :-----------: | :---------: | :-------: | :---------: | :------------: | :---------: | :------: | :--------: | :------: | :------: | :------------------: |
| [Home](home) | [_Gerência_](gerencia) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Código](codigo) | [Banco de Dados](banco_dados) | [Utilização](utilizacao) |
| :----------: | :--------------------: | :------------------: | :------------------------------: | :--------------------------: | :------------------------: | :--------------: | :---------------------------: | :----------------------: |
# Gerência
## Acesso rápido
| [_Geral_](gerencia_geral) | [Sprint 0](gerencia_sprint_0) | [Sprint 1](gerencia_sprint_1) | [Sprint 2](gerencia_sprint_2) | [Sprint 3](gerencia_sprint_3) | [Sprint 4](gerencia_sprint_4) |
| :-----------------------: | :---------------------------: | :---------------------------: | :---------------------------: | :---------------------------: | :---------------------------: |
- Termo de Abertura do Projeto
- Estrutura Analítica do Projeto (EAP)
- User Story
- Cronograma
- Matriz de responsabilidade
- Sprints
<br>
## Matriz de responsabilidades
[Matriz de responsabilidade no Google Sheets](https://docs.google.com/spreadsheets/d/1ehh1Nrq_1UXt9THXKpogVoP5SDiMaa2Av8d8LeQsVpA/edit?usp=sharing)
---
**Sprint 0**
## Escopo
| 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 |
## Cronograma
**Sprint 1,2,3,4**
| Momento | Sprint 0 | Sprint 1 | Sprint 2 | Sprint 3 | Sprint 4 |
| ------------- | ------------- | ------------- | ------------- | ------------- | ------------- |
| Apresentação | 25/03/2022 LM | 22/04/2022 LM | 13/05/2022 LM | 03/06/2022 LM | 24/06/2022 LM |
| Escopo | 25/03/2022 NP | 22/04/2022 NP | 13/05/2022 NP | 03/06/2022 NP | 24/06/2022 NP |
| Retrospectiva | 25/03/2022 NP | 22/04/2022 NP | 13/05/2022 NP | 03/06/2022 NP | 24/06/2022 NP |
| Code freeze | 25/03/2022 NP | 20/04/2022 NP | 13/05/2022 NP | 03/06/2022 NP | 24/06/2022 NP |
| 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**
## Matriz de responsabilidades
|Sprint | Pessoa (R)|
| --------- | ------ |
| 0 | Max Franke |
| 1 | Lucas Schell |
| 2 | Frederico Thofehrn |
| 3 | Max Franke |
| 4 | A Definir |
- P: Participa da atividade
- I: Deve ser informado
- C: Deve ser consultado
- A: Aprova
- R: Responsável pela atividade
| 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 |
| Definir squads | C | R | A | A |
| Definir marcos da sprint | I | I | C | R/A |
| Quebra de tasks | C | C | R | R/A |
| Desenvolvimento | R | R | R/A | C/A |
| Code review | C | C | R/A | C |
| Deploy da aplicação | I | I | R | A |
| Apresentação da review | C | C | C | R |
---
## 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 |
| 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. |
| 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. |