Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C Cosmos
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Cosmos
  • Cosmos
  • Wiki
  • Gerencia

Last edited by Leonardo Vargas Soares Nov 17, 2024
Page history

Gerencia

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

Sumário

  • Sumário
  • Definições de Gerenciamento de Projeto
    • Descrição
  • Gerenciamento de Tarefas
  • Matriz de Responsabilidade
  • Plano de Comunicação
  • Plano de Riscos
  • Documento de Continuação

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 Cosmos, optamos por usar o Azure DevOps 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 (Segundas e Quartas) 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
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

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.
Clone repository
  • Arquitetura
  • Banco de Dados
  • Configuracao
  • Design_mockups
  • Escopo
  • Gerencia
  • Git Workflow
  • Qualidade
  • Home