Yuri Jacques Seixas| Gerência | Instalação | Processo | Design/Mockups | Configuração | Arquitetura | Código | BD | Qualidade | Utilização |
|---|
Acesso rápido
- Termo de abertura do projeto
- Plano de comunicação
- Plano de riscos
- Matriz de responsabilidades
- Plano de Recursos Humanos
Termo de Abertura
Título do Projeto: Diário das Emoções
Cliente: Diana Leonhardt dos Santos e Dr. Alexandre Anselmo Guilherme (GruPEV - Grupo de Pesquisas em Educação e Violência/PUCRS/CNPq)
Semestre: Sexta-feira LMNP – 2022/1
Justificativa do Projeto: O projeto surgiu a partir da identificação, por parte dos autores envolvidos, da necessidade de termos instrumentos de intervenção no espaço escolar voltadas ao desenvolvimento socioemocional dos estudantes. No contexto educacional, uma das diretrizes é o desenvolvimento integral dos estudantes no sentido de “conhecer-se, apreciar-se e cuidar de sua saúde física e emocional, compreendendo-se na diversidade humana e reconhecendo suas emoções e a dos outros, com autocrítica e capacidade de lidar com elas” (BNCC, 2017). O aplicativo está voltado para estudantes do 1º e do 2º ano dos Anos Iniciais, visto que é na faixa etária de 6 a 8 anos de idade que estimula-se, no contexto escolar, o desenvolvimento de habilidades relacionadas ao reconhecimento e à nomeação de emoções em si e nos outros.
Objetivos do Projeto: Desenvolver um aplicativo que objetiva auxiliar estudantes dos Anos Iniciais do Ensino Fundamental – 1º e 2º anos no processo de identificação, nomeação e monitoramento das próprias emoções. O aplicativo visa identificar oscilações de emoções ao longo do ano letivo, contribuindo com a identificação de momentos que possam ser estressantes para os estudantes, como momentos avaliativos, ajudando professores e equipe pedagógica a identificarem e, especialmente, intervirem nesses momentos.
Descrição do Projeto em alto nível: • Cadastro do administrador do aplicativo. • Cadastro do estudante (nome, série, turma). • Identificação e nomeação das emoções (figuras, imagens, vídeos, cenas). • Espaço para o aluno contar como está se sentindo. • Resultado com a criação dos pareceres das identificações das emoções. • Gráficos por estudando, por turma, por série. • Notificações.
Não está no Escopo: -
Tecnologia: Aplicativo móvel, preferencialmente Ipad.
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. Nela é apresentada o projeto a ser desenvolvido e o objetivo por trás do projeto. Essa reunião os envolvidos se alinham referente ao projeto, os desenvolvedores tiram suas dúvidas ocorridas durante a apresentação do cliente e começam o levantamento de requisitos. | Cliente | AGES I, II, III, IV e Cliente | Uma vez | 1 hora e 30 minutos |
| Daily | Todos os integrantes da equipe devem comentar os status de suas tarefas no projeto, informando a equipe o que fez até o momento, o que irá fazer até a próxima daily e se tens alguns impedimento ou dúvida. | AGES IV | AGES I, II, III, IV | Quartas e Sextas às 19:15 | 15 minutos |
| Sprint Review | Demonstra-se, revisa-se e discute-se aquilo que foi trabalhado durante a Sprint, fornecendo informações importantes para a Sprint Planning. | AGES IV | AGES I, II, III, IV e Cliente | Aproximadamente a cada 2 semanas (final da Sprint) | 1 hora |
| Sprint Planning | Planeja-se o trabalho que será realizado durante a Sprint, priorizando-se itens do Product Backlog e movendo-os para o Sprint Backlog. | AGES IV | AGES I, II, III, IV e Cliente | Aproximadamente a cada 2 semanas (início da Sprint) | 30 minutos |
| Sprint Retrospective | A Retrospectiva da Sprint é uma oportunidade para o time se avaliar e criar um plano de melhorias a serem implementadas durante a próxima Sprint. Durante a cerimônia, a equipe discute o que correu bem na Sprint e o que pode ser melhorado na próxima Sprint. Embora melhorias possam ser implementadas a qualquer momento, a Retrospectiva da Sprint oferece uma oportunidade formal para focar na melhoria do processo. | AGES IV | AGES I, II, III, IV | Aproximadamente a cada 2 semanas (final da Sprint) | 1 hora e 30 minutos |
| Tasks Breakdown | Momento em que é realizada a quebra de cada User Story priorizada para a Sprint em tarefas técnicas específicas, mensuráveis, pequenas o suficiente e idealmente paralelizáveis. | AGES III e IV | AGES I, II, III, IV | Aproximadamente a cada 2 semanas (início da Sprint) | 1 hora |
| Squads Breakdown | Momento em que os Gerentes de Projeto se reunem para organizar o time dividindo-o em squads, considerando nessa divisão critérios que visem maximizar a produtividade e efetividade dos desenvolvedores para que assim atinjam o objetivo da entrega estipulada na Sprint. | AGES IV | AGES IV | Aproximadamente a cada 2 semanas (início da Sprint) | 1 hora |
Plano de risco
As pontuações de probabilidade foram definidas em uma escala de 1 a 5, sendo 1 "Improvável" e 5 "Totalmente provável". As pontuações sobre o risco estão também em uma escala de 1 a 5, sendo 1 "Nenhum impacto sobre o projeto" e 5 "Alto impacto sobre o projeto".
| Risco | Probabilidade | Impacto | Severidade | Estratégia | Ações |
|---|---|---|---|---|---|
| Alterações de escopo | 3 | 5 | 20 | Mitigar | Definir escopo no início do projeto e balancear aceitando apenas mudanças pequenas (que não exijam retrabalho) ao decorrer do projeto. |
| Falta de engajamento de membros | 4 | 5 | 20 | Mitigar | Manter comunicação ativa e conversas direcionadas quando isso acontecer. E caso ocorra e esteja impactando demais membros do time, reorganizar tarefas da forma necessária. |
| Entregas atrasadas de User Stories planejadas | 4 | 4 | 16 | Mitigar | 1.Acompanhar desenvolvimento do time; caso um possível atraso seja identificado, auxiliar no que for necessário. 2.Definir tempo de integração de tarefas, para que seja possível desenvolver algumas tarefas pendentes. |
| Problemas inesperados na demostração para o cliente | 4 | 5 | 20 | Eliminar | Realizar testes funcionais para cada contribuição de código e antes da entrega com a versão final da aplicação. |
| Falta de presença do stakeholder | 2 | 5 | 10 | Transferir | Mandar lembretes com 6h de antecedência e manter comunicação aberta e disponível com o stakeholder, assim fica a cargo do mesmo nos avisar com atencedência em caso de falta necessária |
| Entrega de User Stories planejadas antes do fim da sprint | 3 | 5 | 15 | Melhorar | Tendo entregue o que foi planejado, analisar capacidade para mais USs dentro do nosso planejamento da Sprint |
| Falta de espaço no Firebase | 4 | 4 | 16 | Transferir | Transferir essa necessidade para o stakeholder, para que ele possa aumentar o plano no Firebase. |
| Falta de recursos financeiros para a conta desenvolvedora da plataforma iOS | 4 | 4 | 16 | Transferir | Transferir essa necessidade para o stakeholder, para que ele possa adquirir a conta desenvolvedora. |
Matriz de responsabilidades
As responsabilidades foram, no geral, atribuídas de acordo com os papéis da AGES (I, II, III e IV); como a sprint 0 é a iniciação do projeto, e possui atividades diferentes das demais sprints, a matriz foi quebrada em duas: uma com atividades da sprint 0, e outra com as atividades das outras sprints.
Sprint 0
| Atividade | AGES I | AGES II | AGES III | AGES IV |
|---|---|---|---|---|
| Alimentar a wiki | R | R | R | R |
| Definir ferramenta de mockups | C | R | A | A |
| Desenvolver mockups | C | R/A | C | A |
| Definir tecnologias (front/back) | C | C | R/A | A |
| Criar projeto inicial (Flutter) | I | I | R/A | A |
| Criar projeto inicial (Firebase) | I | I | R/A | A |
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
| Criar User Stories | C | C | C | R/A |
| Realizar estudos dirigidos | R | R | R | R |
| Documentação de requisitos | R/A | C | C | A |
| Modelar o BD (conceitual/lógico) | I | R/A | R/A | A |
| Apresentar no dia 25/03 | C | C | C | R |
Sprint 1
| Atividade | AGES I | AGES II | AGES III | AGES IV |
|---|---|---|---|---|
| Alimentar a wiki | R | R | R | R |
| Definir squads | C | C | C | R |
| Definir marcos da sprint | I | I | C | R/A |
| Quebra de tasks | C | C | R | R/A |
| Desenvolvimento | R | R | R/A | C/A |
| Code review | C | C | R/A | C |
| Executar testes funcionais* | A | A | C/A | C/A |
| Deploy da aplicação | I | I | R | A |
| Definir plano de comunicações | I | I | I | R/A |
| Definir organização do time | I | I | C | R/A |
| Apresentação da review | C | C | C | R |
Sprint 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 |
| Definir marcos da sprint | I | I | C | R/A |
| Quebra de tasks | C | C | R | R/A |
| Desenvolvimento | R | R | R/A | C/A |
| Code review | C | C | R/A | C |
| Executar testes funcionais* | A | A | C/A | C/A |
| Deploy da aplicação | I | I | R | A |
| Apresentação da review | C | C | C | R |
Plano de Recursos Humanos
| Cargo | Nome |
|---|---|
| Stakeholders | Diana Leonhardt dos Santos e Alexandre Anselmo Guilherme |
| Professor orientador | Azriel Majdenbaum |
| Ages I | João Victor Rhoden Machado, Pedro Henrique Battistella Vieira, Pedro Henrique Semensato Machado e Victor Dos Santos Cruz |
| Ages II | Arthur Da Silva Maia, Bruno Breyer Garcia e Leonardo José Machado Canto |
| Ages III | Carolina Schmitt Fração e Rafael Dos Santos Cardoso |
| Ages IV | Iuri Jaques Seixas, Joseph Douglas Affeldt Weber e Leonardo Freitas da Veiga |