Skip to content

GitLab

Last edited by Eduardo Schweitzer
Page history

gerencia

Home Escopo e Cronograma Mockups Configuração Arquitetura BD Instalação GP Processo Horários

Página de Gerenciamento do Projeto

Tópicos

Termo de Abertura

Versão em PDF

Título do Projeto: MUTIRÃO DO BEM

Justificativa do Projeto: Este projeto nasceu da vontade de fazer o bem social, indo muito além da entrega de cestas básicas e roupas que são ajudas mais pontuais. A proposta é fazer algo bem mais efetivo que permita conectar pessoas e organizações no auxílio de causas sociais identificadas, criando oportunidades para famílias carentes, creches, asilos, desde doar um fogão, ou uma atividade que auxilie outras pessoas como treinamentos.

Objetivos do Projeto: Desenvolver um aplicativo que conecte organizações, pessoas e comunidades, simulando uma Inteligência Colaborativa que as une através dos mais variados tipos de mutirões, com objetivos de auxiliar quem necessite através de algum bem ou serviço, deixando um legado para a família e/ou comunidade.

Descrição do Projeto em alto nível:

  • Login
  • Cadastro das Entidades (Asilos, Creches, Pessoas)
  • Cadastro de Causas
    • Atividades ligadas as causas
    • Necessidades de Pessoas
  • Cadastro de Voluntários (Pessoas e empresas)
    • Tempo e hora disponível
    • Causas selecionadas pelo voluntário
  • Geolocalização para apresentar as causas cadastradas para esta cidade
  • Gerenciamento das Causas
  • SMS de Ajuda

Tecnologia: Aplicativo Mobile

Cliente

Estevão Leuck

Papéis e Responsabilidades dos Gerentes de Projeto

No início do projeto foi decidio que todos os GPs atuariam nos três papéis descritos abaixo.

Papéis gerais

  • Acompanhar o time no desenvolvimento do projeto
  • Criar e acompnhar a documentação na wiki
  • Monitorar e atualizar o Trello
  • Identificar impedimentos e reportar aos outros GP's e lideranças técnicas.
  • Realizar testes funcionais da aplicação
  • Preparar a apresentação de entrega de sprint

Papéis de Scrum Master e PO

  • Conduzir a sprint planning
  • Conduzir a estimativa das tarefas da equipe
  • Conduzir e documentar as dailies
  • Fazer a montagem inicial do Trello
  • Apresentação da Sprint para os Stakeholders

Papéis técnicos

  • Acompanhar as squads no desenvolvimento
  • Auxiliar com a produção de código, se necessário
  • Monitorar qualidade da arquitetura e Banco de Dados
  • Monitorar e levantar eventuais impedimentos
  • Definir deadlines para que o conteúdo desenvolvido esteja no ambiente de homologação da AGES

Estrutura analítica de projeto (EAP)

Estrutura Analítica do Projeto

Plano de Comunicação

Evento Descrição Responsável Envolvidos Frequência Duração
Kickoff A reunião de Kickoff é a primeira reunião entre o time e o Cliente do projeto, os Stakeholders. Nela é apresentada a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitando um levantamento inicial dos requisitos do projeto por parte da equipe, com o auxílio do cliente, que detém o conhecimento sobre o produto a ser desenvolvido. AGES IV e Cliente AGES I, II, III, IV e Cliente Uma vez no início do semestre 1 hora e 30 minutos
Daily Cada integrante do time atualiza os demais sobre o que fez desde o último encontro síncrono, o que pretende fazer em seguida e se tem impedimentos para que possam ser solucionados. As dailies são registradas pelos AGES IV AGES IV AGES I, II, III, IV Terças-feiras via Discord (19:00) e Sextas-feiras às 19:15 (início dos encontros síncronos) Máximo 25 minutos
Sprint Review Momento de apresentar para o Cliente o resultado do que foi desenvolvido durante a Sprint coletando validações e inputs dos Stakeholders para cada atividade do Sprint Backlog. AGES IV AGES I, II, III, IV e Cliente No final de cada sprint 45 minutos - 1 hora
Sprint Planning Decisão, junto ao cliente, das tarefas que serão realizadas durante a sprint seguinte. AGES IV AGES I, II, III, IV e Cliente No final de cada sprint 30 minutos
Sprint Retrospective Momento onde o time reflete sobre a sprint anterior, levantando os pontos bons, ruin e melhorias (Action Items). Também é feita a votação do membro destaque da sprint. AGES IV AGES I, II, III, IV No final de cada sprint 1 hora

Matriz de Responsabilidade

As responsabilidades foram atribuidas com base nos níveis de AGES.
Foi criada uma matriz específica para a sprint 0, pois ela possui atividades diferentes das demais.

Significado das letras:

Letra Papel
R Responsável
A Autoridade
C Consultado
I Informado

Sprint 0

Atividade AGES I AGES II AGES III AGES IV
Definir organização do time I I I R/A
Realizar estudos dirigidos R R R R
Alimentar a wiki R R R A
Definir tecnologias (front/back) C C R R/A
Definir ferramenta de mockups R R R R
Desenvolver mockups R R/A I I
Documentação de requisitos R R I R
Criar User Stories R R I R/A
Criar projeto inicial (front/back) I I R/A I
Modelar o BD (conceitual/lógico) I R/A R/A C
Documentar arquitetura inicial do projeto I R R/A I
Apresentação Sprint 0 C C C R

Sprints 1, 2, 3 e 4

Atividade AGES I AGES II AGES III AGES IV
Alimentar a wiki R R R R
Definir squads C C C R
Quebra de tasks R R R R
Desenvolvimento R R R/A C/I
Code review R R R R
Deploy da aplicação I I R/A I
Apresentação das Sprints C C C R

Plano de Riscos

Risco Probabilidade Impacto Severidade Estratégia Ações
Alterações no escopo do projeto 7 5 35 Mitigar Evitar grandes mudanças no escopo asó a definição inicial, aceitando somente mudanças que não necessitem de muito retrabalho.
Falta de engajamento dos membros do time 4 7 28 Mitigar Acompanhar o desenvolvimento das tarefas no Trello. Fazer reuniões periodicas (dailies) para saber sobre o progresso do desenvolvimento. Caso haja impacto no time, conversar com os membros do time e replanejar as tarefas caso necessário.
Não entregar as User Stories do sprint backlog 5 6 30 Mitigar Acompanhar o desenvolvimento das atividades no Trello e realizar reuniões periódicas com o time para saber sobre o progresso do desenvolvimento, ressaltando o tempo limite da sprint.
Problemas inesperados no sprint delivery 3 8 24 Eliminar Testar a aplicação na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência da entrega da sprint.
Ausência do cliente no sprint delivery 1 8 8 Transferir Relembrar o cliente da entrega da sprint.
Impossibilidade de homologação na AWS 3 2 6 Transferir Realizar a homologação em uma plataforma alterativa, como Digital Ocean. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente. Encontrar e corrigir o problema antes da próxima entrega.
Falta de créditos da AGES para homologação na AWS 2 4 16 Transferir Realizar a homologação em uma plataforma alterativa, como Digital Ocean. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente.
Atingir o limite de uso gratuito da API de mapas 2 6 12 Transferir Alterar a implementação para utilizar alguma outra opção gratuita de API de mapas.
Falta de conhecimento nas tecnologias utilizadas 6 6 36 Mitigar Recomendar documentações e tutoriais sobre as tecnologias utilizadas para os membros do time. Desenvolver utilizando pair programming para compartilhamento de conhecimento.