Skip to content

GitLab

Last edited by Leonardo Vargas Soares
Page history

gerencia

Home Escopo Git Workflow Design/Mockups Configuração Arquitetura Gerência BD Qualidade

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

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 a identificação de débitos técnicos, a implementação de IA para recomendações, e os procedimentos de upload do sistema na AWS, além da publicação do aplicativo na Play Store e Apple Store, garantindo a estabilidade e a continuidade do projeto.
  • Para acessar o documento do plano de continuidade clique aqui.