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.
Sumário
Azure DevOps - Para Gerenciamento de Tarefas
- Overview Azure DevOps - Projeto Cosmos
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 |
Três vezes na semana, duas síncronas (Terças e Quintas) e outra assíncrona (Sábado) |
15 minutos; |
Sprint Review |
Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Esse evento é uma preparação para a Sprint Planning, pois podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. |
AGES IV |
AGES I, II, III, IV e Cliente(s) |
Sempre no final das Sprints. Aproximadamente a cada 3 semanas. |
Entre 30 minutos - 1 hora |
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 |
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 |
Documento de Continuação
- Este documento de continuidade abrange as informações necessárias para garantir a estabilidade e a continuidade do projeto.
- Para acessar o documento do plano de continuidade clique aqui.