| ... | @@ -8,6 +8,61 @@ |
... | @@ -8,6 +8,61 @@ |
|
|
<th> [Arquitetura](arquitetura) </th>
|
|
<th> [Arquitetura](arquitetura) </th>
|
|
|
<th> [Infraestrutura](infraestrutura) </th>
|
|
<th> [Infraestrutura](infraestrutura) </th>
|
|
|
<th> [BD](banco de dados) </th>
|
|
<th> [BD](banco de dados) </th>
|
|
|
<th> [Gerência](gerencia) </th>
|
|
<th> [Gerência](gerência) </th>
|
|
|
</tr>
|
|
</tr>
|
|
|
</table> |
|
</table>
|
|
\ No newline at end of file |
|
|
|
|
|
# Sumário
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
# Definições de Gerenciamento de Projeto
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
- Esta seção apresenta como a gerência do projeto foi feita, como o time está organizado, como trabalha, e quais são os processos de desenvolvimento.
|
|
|
|
|
|
|
|
# Gerenciamento de Tarefas
|
|
|
|
|
|
|
|
- No Projeto Plataforma de Marketing e Sales Analytics (RevForce), optamos por usar o ClickUp para o gerenciamento de tarefas. A plataforma oferece uma abordagem integrada para controle de backlog, sprints e acompanhamento de progresso, facilitando a colaboração entre equipes de desenvolvimento. Essa escolha visa melhorar a eficiência, organização e visibilidade do progresso do projeto, garantindo que prazos e objetivos da sprint sejam atingidos.
|
|
|
|
|
|
|
|
# Matriz de Responsabilidade
|
|
|
|
|
|
|
|
- Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
|
|
|
|
|
|
|
|
| **Atividades** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
|
|
|
|
| -------------------------- | :--------: | :---------: | :----------: | :---------: |
|
|
|
|
| Gerenciar a Wiki | R | R | R | R |
|
|
|
|
| Organização do Time | I | I | C | R |
|
|
|
|
| Definir Marcos da Sprint | I | I | C | R |
|
|
|
|
| Divisão de Tasks | C | C | C | R/A |
|
|
|
|
| Desenvolvimento | R | R | R/A | C/R/A |
|
|
|
|
| Code review | C | C | R/A | C/R/A |
|
|
|
|
| Execução de Testes | R | R | C/R | I |
|
|
|
|
| Deploy | I | I | R | R/A |
|
|
|
|
|
|
|
|
- R: Responsável: Quem é designado para trabalhar na atividade;
|
|
|
|
- A: Aprovador: Quem tem autoridade para aprovar a atividade;
|
|
|
|
- C: Consultado: Quem deve ser consultado e participar da atividade;
|
|
|
|
- I: Informado: Quem deve ser informado sobre o andamento da atividade.
|
|
|
|
|
|
|
|
# Plano de Comunicação
|
|
|
|
|
|
|
|
| **Evento** | **Descrição** | **Responsável** | **Envolvidos** | **Frequência** | **Duração** |
|
|
|
|
| :--------------------------: | :--------: | :---------: | :----------: | :---------: | :---------: |
|
|
|
|
| 1ª Reunião com o Cliente | 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, para ajudar nas definições dos requisitos do projeto em conjunto com o cliente. | Cliente(s) | AGES I, II, III, IV e Cliente(s) | Uma vez (início do projeto) | Entre 1 hora - 1 hora e 30 minutos |
|
|
|
|
| Daily | Cada membro da equipe atualiza os outros sobre o que produziu desde o último encontro síncrono (ou assíncrono via Discord), o que visa fazer em seguida, e se tem obstáculos, com finalidade de que possam ser discutidos e resolvidos. | AGES IV | AGES I, II, III e IV | Duas vezes na semana (Terças e Quintas) | 15 minutos; |
|
|
|
|
| Sprint Planning | É realizado o planejamento do que irá ser feito durante a Sprint que se inicia. Realizada a priorização das User Stories que estão no Product Backlog para o Sprint Backlog atual do projeto. | AGES IV | AGES I, II, III e IV | No início das Sprints. Aproximadamente a cada 3 semanas. | Entre 15 minutos - 30 minutos |
|
|
|
|
| Sprint Retrospective | Momento em que a equipe revisa como foi o processo e o trabalho do time na Sprint. Os membros são incentivados para expor o que gostaram, o que não gostaram, com quem gostaram de trabalhar e qualquer comentário construtivo sobre a Sprint que se encerra. Como output desse encontro, temos itens de ação para aprimorar e melhorar processos que não foram produtivos na Sprint seguinte. | AGES IV | AGES I, II, III e IV | No final das Sprints. Aproximadamente a cada 3 semanas | Entre 45 minutos - 1 hora |
|
|
|
|
| Tasks/Squads Planning | Evento realizado pela gerência, com o intuito de dividir o time em Squads focando produtividade. A divisão é pensada para maximizar desempenho na sprint atual. Após a divisão dos squads, é realizada a quebra das User Stories priorizadas para a Sprint atual em tarefas. Essas tarefas são divididas entre os squads e, consequentemente, entre seus integrantes. As tarefas possuem o menor escopo possível e critérios de aceitação mensuráveis para cada integrante. | AGES IV | AGES IV | No início das Sprints. Aproximadamente a cada 3 semanas. | Entre 1 hora - 1 hora e 30 minutos |
|
|
|
|
| Code Review and Deploy Meeting | Reunião para definição dos responsáveis pela revisão de código e para revisão da apresentação final da Sprint. | AGES IV | AGES III | No final das Sprints, um final de semana antes da entrega. Aproximadamente a cada 3 | Entre 1 hora - 1 hora e 30 minutos |
|
|
|
|
| Code Freeze | Marca o prazo final no qual nenhuma nova funcionalidade ou mudança significativa de código pode ser introduzida no projeto. A partir desse momento, o foco está em garantir a estabilidade do sistema, realizando apenas correções de bugs críticos e ajustes necessários para garantir o sucesso da entrega. O objetivo principal é mitigar riscos e assegurar que o produto passe por uma fase final de estabilização antes da entrega ao cliente ou ao usuário final. | AGES I, II, III, IV | AGES I, II, III, IV | No final das Sprints, entre 2 a 3 dias antes da entrega. | Até o final da Sprint (aproximadamente 1 semana). |
|
|
|
|
|
|
|
|
# Plano de Riscos
|
|
|
|
|
|
|
|
| **Risco** | **Prevenção** | **Contingência** | **Estratégia** |
|
|
|
|
| :--------------------------: | :--------: | :---------: | :----------: |
|
|
|
|
| Falha na Comunicação com Stakeholder. | Manter canal de comunicação aberto com stakeholder e incentivar comunicação. | Revisar documentação e entrar em consenso com o time sobre estratégia a ser adotada. | Mitigar |
|
|
|
|
| Atraso na Entrega | Revisar constantemente as tarefas e o andamento dos épicos a cada sprint | Focar esforço no trabalho atrasado | Mitigar |
|
|
|
|
| Falta de Conhecimento nas Tecnologias Utilizadas | Incentivar estudos dirigidos | Fornecer matérias de estudo e realizar pair-programming para balancear conhecimento nas duplas | Mitigar |
|
|
|
|
| Falta de Motivação na Equipe | Lideranças devem acompanhar tarefas e verificar constantemente a moral da equipe | Eventos de comemoração e interação | Aceitar |
|
|
|
|
| Alterações de Escopo | Fechar o escopo do projeto com os stakeholders antes do início do desenvolvimento | Negociar com stakeholders a troca de itens para não alterar o tamanho do escopo | Mitigar | |
|
|
|
\ No newline at end of file |
