Skip to content

GitLab

Last edited by Eduardo Schweitzer
Page history
This is an old version of this page. You can view the most recent version or browse the history.

gerencia

Home Escopo e Cronograma Mockups Configuração Arquitetura BD Instalação Gerência Qualidade Processo Versionamento 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.