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 a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitanto 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. | Cliente | AGES I, II, III, IV e Cliente | Uma vez | 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 removidos. | 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 inspecionar e criar um plano de melhorias a serem implementadas durante a próxima Sprint. Durante o evento, 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 inspeção e adaptação. | 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. | 
| Não ter 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 (front/back) | I | I | R/A | A | 
| Definir estratégia de Verificação e Validação | I | C | R/A | C/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 | 
| Definir plano de comunicações | I | I | I | R/A | 
| Definir organização do time | I | I | C | R/A | 
| Documentação de requisitos | R/A | C | C | A | 
| Modelar o BD (conceitual/lógico) | I | R/A | R/A | A | 
| Apresentar no dia 31/08 | C | C | C | R | 
Sprint 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 | 
| 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 | 
