Home	Sprints	Requisitos	Arquitetura	Configuração	Mockups	BD	Instalação	GP	Horários	Processo

Página de Gerenciamento do Projeto

Nesta página, deve ser apresentado as seguintes informações:

1. Termo de Abertura (Atualização)
2. Identificação dos Stakeholders
3. Papéis e Responsabilidades dos Gerentes de Projeto
4. Estrutura analítica de projeto (EAP)
5. User Stories
6. Cronograma
7. Plano de Comunicação
8. Matriz de Responsabilidade
9. Plano de Riscos

1. Termo de Abertura

Versão em PDF

Título do Projeto: CINE CLUBE

Semestre: Sexta-Feira LM NP – 2021.1

Justificativa do Projeto: Este projeto pretende enfrentar o problema da “fadiga decisória”, fenômeno psicológico causado pelo excessivo número de escolhas com que alguém se depara diariamente. Nesses casos, o sujeito passa a tomar más decisões ou mesmo a evitá-las, olhando demoradamente para as opções disponíveis sem conseguir escolher nenhuma. Para contornar esse estressante problema, o catálogo do Cineclube contemplará apenas filmes pré-selecionados pela equipe curadora, com breves sinopses e uma justificativa do porquê cada um merece ser assistido. O Cineclube será um serviço de curadoria de filmes com foco nos títulos disponíveis nos principais serviços de streaming, também organizará, periodicamente, debates sobre determinados filmes, conduzidos por um de nossos mediadores.

Objetivos do Projeto: Desenvolvimento de aplicativo que facilite a escolha de filmes por meio de um serviço de curadoria manual com auxílio de algoritmos, criar espaços de interação entre os usuários, possibilitando a formação de uma comunidade voltada para a avaliação e discussão de filmes.

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

• Login (Google Sign-In).
• Lista pessoal de filmes assistidos/recomendados/por assistir (IMDb API).
• Página para cada um dos filmes catalogados, incluindo suas informações básicas, texto e tags da equipe curadora, bem como um espaço para que os usuários comentem e avaliem.
• Barra de busca com filtros diversos.
• Opção de seguir outros usuários.
• Feed com divulgação dos debates e conteúdo diverso.

Não está no Escopo: Plataforma para as reuniões virtuais.

Tecnologia: Progressive Web App (PWA)

2. Identificação dos Stakeholders

• Christiano Pozzer, Graduado em Design de Produto pela UFRGS e Mestrando em Design e Tecnologia pelo PGDesign da UFRGS
• Gabriela Richinitti, Graduada em Direito pela UFRGS e Doutoranda em Escrita Criativa pela PUCRS
• Lucas Furtado, Graduado em Cinema pela Unisinos e Doutorando em Comunicação pela UFRGS
• Renato Weber, Graduando em Direito pela UFRGS

3. Papéis e Responsabilidades dos Gerentes de Projeto

A partir da primeira Sprint, os Gerentes de Projeto dividirão suas atribuições de forma rotativa, representando os papéis abaixo:

Papéis permanentes de todos os GP's

• Estar atento à equipe e ao andamento do projeto como um todo
• Auxiliar nos registros da Wiki
• Monitorar Trello
• Identificar impedimentos e reportar aos outros GP's e lideranças técnicas.
• Realizar testes funcionais da aplicação
• Auxiliar na preparação da apresentação
• Tomar nota das reuniões

Scrum Master & PO

• Conduzir a Planning da Sprint
• Conduzir a estimativa das tarefas da equipe
• Fazer a montagem inicial do Trello
• Comandar as dailies, escolhendo um secretário entre os outros 2 GP's para registrar o que foi dito
• Ensaiar a apresentação da Sprint
• Apresentação da Sprint para os Stakeholders

GP Front-end e GP de Back-end

• Estar próximo à equipe respectiva
• Auxiliar com a produção de código, se necessário
• Monitorar qualidade da arquitetura e Banco de Dados
• Analisar os PR's dos colegas
• Monitorar e levantar eventuais impedimentos
• Trazer para discussão problemas técnicos encontrados de difícil solução para discussão de alternativas
• Definir deadlines para que o conteúdo desenvolvido esteja no ambiente de homologação da AGES

4. Estrutura analítica de projeto (EAP)

A EAP em projetos ágeis permite visualizar, com facilidade, todo o escopo do projeto, agrupado pelas entregas feitas à cliente (por sprint). No Appoio, as stories foram agrupadas de acordo com seus épicos (quando possível, respeitando a sintaxe da EAP); apenas a sprint 0 não possui USs como pacotes de trabalho.

A EAP é desenvolvida no início do projeto e atualizada conforme mudanças de escopo são feitas. A versão mais atualizada encontra-se abaixo.

6. Cronograma

🔗 Versão PDF

Além das datas principais de cada sprint, as sprints de desenvolvimento (1, 2, 3 e 4) também contam um cronograma para a realização das principais atividades do time, como limite para a abertura de merge requests, período de integrações ao fim da sprint e período para a execução de testes funcionais manuais.

Iniciação | 05/03/2021

• 05/03: apresentação da AGES;
• 05/03: apresentação do processo da AGES, Fluxo AGES e artefatos.

Sprint 0 | 12/03 a 26/03

• 12/03: 👥 integração do time;
• 12/03: 🗓 apresentação do projeto pela stakeholder (reunião de levantamento de requisitos);
• 26/03: 🌟 apresentação dos mockups e user stories à stakeholder (Sprint Review);
• 26/03: ⚙️ Sprint Retrospective;
• 26/03: 📝 entrega do relatório da sprint (❗️).

Sprint 1 | 26/03 a 16/04

• 26/03: 🗓 Sprint Planning;
• 16/04: 🌟 Sprint Review;
• 16/04: ⚙️ Sprint Retrospective;
• 16/04: 📝 entrega do relatório da sprint (❗️).

Sprint 2 | 16/04 a 30/04

• 16/04: 🗓 Sprint Planning;
• 30/04: 🌟 Sprint Review;
• 30/04: ⚙️ Sprint Retrospective;
• 30/04: 📝 entrega do relatório da sprint (❗️).
• 30/04: 📝 entrega do relatório de Andamento (❗️❗️❗️).

Sprint 3 | 30/04 a 28/05

• 30/04: 🗓 Sprint Planning;
• 25/05: 🌟 Sprint Review;
• 25/05: ⚙️ Sprint Retrospective;
• 12/05: 📝 entrega do relatório da sprint (❗️).

Sprint 4 (Final Sprint) | 28/05 a 25/06

• 28/05: 🗓 Sprint Planning;
• 18/06: 🌟 Sprint Review;
• 18/06: ⚙️ Sprint Retrospective;
• 18/06: 📝 entrega do relatório da sprint (❗️).

Encerramento | 25/06 a 09/07

• 02/07: 🌎 retrospectiva da AGES (‼️);
• 02/07: 🌎 apresentação dos projetos para todos os times (‼️);
• 09/07: one-on-one.

7. 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.	AGES IV	AGES I, II, III, IV	Terças-feiras via Discord (durante todo o dia) e Sextas-feiras às 19:15 (início dos encontros síncronos)	Máximo 30 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	A cada final de Sprint	45 minutos - 1 hora
Sprint Planning	Planeja-se o trabalho que será realizado durante a Sprint, priorizando itens do Product Backlog e movendo-os para o Sprint Backlog. Além da colaboração do Cliente para decidir quais USs são prioritárias, contamos com a colaboração de todos integrantes do time para decidirmos a carga de trabalho que temos capacidade de responsabilizar-nos.	AGES IV	AGES I, II, III, IV e Cliente	A cada final de 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. Em seguida, em cima do que pode ser melhorado, são levantados Action Items para que todos busquem efetivar essas mudanças. 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	A cada final de Sprint	1 hora
Tasks Breakdown	Momento em que é realizada a quebra e a documentação no Trello 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 de cada Squad	Integrantes de cada Squad	A cada final de Sprint	30 minutos

8. Matriz de Responsabilidade

As responsabilidades foram, em geral, atribuídas de acordo com os papéis da AGES (I, II, III e IV); porém, como a Sprint 0 é a iniciação do projeto e possui atividades diferentes das demais Sprints, ela possui uma matriz própria para suas atividades. Já segunda matriz é em relação às Sprints de 1 a 4.

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	C	R/A
Definir ferramenta de mockups	R	R	R	R
Desenvolver mockups	R	R/A	I	I
Documentação de requisitos	R/A	R	I	I
Criar User Stories	R/A	R	I	I
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/A	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
Definir marcos da sprint	I	I	I	R/A
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

9. Plano de Riscos

Risco	Probabilidade	Impacto	Severidade	Estratégia	Ações
Alterações no escopo do projeto	4	4	16	Mitigar	Definir corretamente o escopo no início do projeto e conferir o que foi levantado com os stakeholders. Além disso, balancear aceitando no decorrer do projeto somente mudanças pequenas que não exijam retrabalho.
Falta de engajamento dos membros do time	3	7	21	Mitigar	Manter tracking do desenvolvimento das atividades no Trello e fazer checkpoints periódicos com as squads. Caso ocorra e impacte o resto do time e as entregas, conversas diretamente com o membro do time e reorganizar as atividades conforme necessário.
Não entregar as User Stories do sprint backlog	3	6	18	Mitigar	Manter tracking do desenvolvimento das atividades no Trello, fazer checkpoints periódicos com as squads e sempre garantir que não há algum impedimento com qualquer membro. Além disso, sempre deixar claro o deadline de entrega das USs, que deve ser, por precaução, pelo menos 2 dias antes da sprint delivery.
Problemas inesperados no sprint delivery	3	7	21	Eliminar	Efetuar testes funcionais no código e na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência do sprint delivery.
Ausência do stakeholder no sprint delivery	2	8	18	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 antecedência em caso de falta necessária
Impossibilidade de homologação na AWS	8	2	16	Transferir	Transferir a homologação para alguma plataforma alternativa, como Heroku, e identificar por que não foi possível utilizar a AWS e solucionar o problema.
Falta de créditos da AGES para homologação na AWS	4	4	16	Transferir	Transferir a homologação para alguma plataforma alternativa, como Heroku, caso o stakeholder não queira disponibilizar uma conta na AWS para homologação.