Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • histotéria wiki histotéria wiki
  • 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
  • Histotéria
  • histotéria wikihistotéria wiki
  • Wiki
  • Gerência

Last edited by Vittoria C Presa Nov 06, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Gerência

Plano de Riscos

Risco Prevenção Contingência Estratégia
Requisitos Ausencia de domínio/conhecimento Comunicação frequente com o cliente, para definição de requisitos Entrar em contato com cliente o mais rápido possível Transferir
Requisitos Instabilidade nos requisitos definidos Denir os requisitos básios do sistemas, que são os principais Limitar o escpo com o cliente Mitigar
Requisitos Definições incompletas, com poucos informações Reuniões com perguntas claras e objetivas sobre os requisitos do sistema Elaborar o MVP da funcionalidade em questão Mitigar
Cliente Ausencia de comprometimento do cliente Ter conversar constantes com o cliente Não ha contingência sem comprometimento do cliente Aceitar
Cliente Falta de disponibilidade do cliente Em todos reuniões presenciais fazer o maior número de peruntas objetivas possíveis Lidar os requisitos fornecidos e implementar o básico combinado Aceitar
Cliente Cliente não retorna as duvidas relacionadas ao sistema Cobrar resposta do cliente caso não se tenha resposta em até 4 dias uteis Deixar funcionalidade como débito e implementar as funcionalidades com requisitos claros Aceitar
Projeto Não entregar a feature na Sprint Comprender a funcionalidade e e solicitar ajuda caso necessário Colocar a funcionalidade como debéto tecnico para próxima sprint Transferir
Projeto Features definidar de maneira errada Conversar com o cliente para definir bem os requisitos Colocar no backlog a correção da funcionalidade Aceitar
Ambiente Estudantil Falta de disponibilidade para realizar as atividades Comunicar ao time dias que se tera disponibilidade para trabalhar ou participar de reuniões Pedir mais comprometimento em relação as faltas no projeto Mitigar
Ambiente Estudantil Acumulo de trabalhos dos estudantes, somando todas as cadeiras Não deixar trabalhos acomularem no final do semestre Comunicar a necessidade de focar em outras displinas para que o time possa se organizar Mitigar
Tecnologia Dificuldade com algma tecnologia especifica Olhar material disponibilizado por colegar para aprendizado Realizar treinamento presencial/remoto da tecnlogia para melhor entendimento Mitigar
Pessoas Baixa afinidade da equipe Comunicação continua com os integrantes do time Relizar uma integração com o time durante um encontro presencial para motivação da equipe Mitigar
Pessoas Ausência de competência técnica Realizar treinamentos dirigidos das tecnologias relacionadas Marcar um encontro remoto com algum colega que saiba mais para entender Mitigar
Gerenciabilidade Ineficiente definição de papeis e responsabilidades Organizar papeis atividades de cada recurso do time com antecedência Definir atividades por meio de uma comunicação direta Mitigar
Gerenciabilidade Ditribuição das Histórias de usuiário Criação de todas US e seus respectivos detalhamentos o o quanto antes para encaminhar para o time Definir o mínimo necessário da história para dar inicio ao desenvolvimento Mitigar

Plano de Comunicação

Evento Descrição Responsáveis Envolvidos Frequência Tempo
KickOff A reunião de Kickoff é o primeiro encontro entre o time e cliente. Neste momento o cliente apresenta o projeto e o seu objetivo. Neste momemento o time faz perguntas a fim de entendimento. Cliente AGES I, II, III, IV e Cliente Uma vez 1:30h
Daily Todos da equipe devem comentar sobre suas tarefas, indicando o que foi feito, o que falta ser feitos e se possui algum impedimento para a relização de suas tarefas. AGES IV AGES I, II, III, IV Sexta-feira 19:15(Início da Aula) 15 minutos
Sprint Review Neste momento, o time revisa tudo que foi trabalhado durante a Sprint, informando pontos importantes para a próxima Sprint. AGES IV AGES I, II, III e IV A cada 2 semanas, quando finaliza a Sprint 30 minutos
Sprint Retrospective Aqui o time utiliza o momento para oportunidade de melhorias de processo para a próxima Sprint, por mais que a Sprint anterior possa ter sido perfeita, sempre podemos encontrar uma melhoria no nosso processo. AGES I, II, III, IV AGES I, II, III e IV A cada 2 semanas, quando finaliza a Sprint 1 hora
Sprint Planning Neste momento, o time planeja tudo que deve ser feito durante a Sprint, os arquitetos(AGES III) estará organizando sua nova equipe, sendo assim, fazendo o rodizio de AGES I e II em ambos os times(Back/Front) AGES III e IV AGES I, II, III e IV A cada 2 semanas 1:30h

Clone repository
  • Banco de Dados
  • Gerência
  • arquitetura
  • backend
  • design_mockups
  • Home
  • processo