gerencia

This is an old version of this page. You can view the most recent version or browse the history.

Home	Escopo	Processo	Design/Mockups	Configuração	Arquitetura	Gerência	Código	BD	Qualidade	Frontend	Backend

Sumário

Estrutura Analítica do Projeto
Cronograma
Plano de comunicação
Plano de riscos

Estrutura Analítica do Projeto

A Estrutura Analítica de Projeto (EAP), especialmente aplicada em metodologias ágeis, desempenha o papel fundamental de proporcionar uma visão holística e acessível de todo o âmbito do projeto, organizando-o com base nas entregas realizadas aos clientes em cada sprint. No contexto do projeto "Appoio", as histórias de usuário foram agrupadas em consonância com seus respectivos épicos sempre que possível, alinhando-se à estrutura da EAP. Cabe notar que somente a sprint 0 não contém Histórias de Usuário designadas como pacotes de trabalho.

A construção da EAP ocorre no estágio inicial do projeto e é continuamente atualizada à medida que alterações no escopo se manifestam. A versão mais recente dessa estrutura encontra-se apresentada abaixo, refletindo o estado atual das entregas e do escopo do projeto.

-- colocar EAP aqui

Cronograma

Além de destacar as datas-chave para cada sprint, é relevante notar que as sprints de desenvolvimento numeradas de 1 a 4 estão estruturadas com um cronograma que abrange as principais atividades da equipe. Isso inclui marcos importantes, como os prazos para a abertura de solicitações de integração de código (merge requests), o período destinado às integrações ao final de cada sprint e uma janela reservada para a realização de testes funcionais manuais.

O cronograma delineado para essas atividades cruciais assegura a sincronização eficiente dos esforços da equipe, possibilitando a revisão do código, a unificação das contribuições individuais e a verificação rigorosa da funcionalidade através de testes manuais. Esse planejamento meticuloso promove a coesão da equipe e a entrega consistente de resultados de alta qualidade ao longo de cada sprint.

Iniciação | 02/08 a 07/08

02/08: apresentação da AGES;
07/08: apresentação do processo da AGES, Fluxo AGES e artefatos.

Sprint 0 | 12/08 a 02/09

09/08: 🗓 apresentação do projeto pela stakeholder;
23/08: 🌟 apresentação dos mockups e user stories à stakeholder (Sprint Review);
28/08: ⚙️ Sprint Retrospective;
28/08: 📝 entrega do relatório da sprint.

Sprint 1 | 23/08 a 13/09

23/08: 🗓 Sprint Planning;
13/09: 🌟 Sprint Review;
18/09: ⚙️ Sprint Retrospective;
18/09: 📝 entrega do relatório da sprint;
18/09: 📜 entrega do relatório de andamento.

Sprint 2 | 13/09 a 11/10

13/09: 🗓 Sprint Planning;
11/10: 🌟 Sprint Review;
16/10: ⚙️ Sprint Retrospective;
16/10: 📝 entrega do relatório da sprint.

Sprint 3 | 14/10 a 30/10

11/10: 🗓 Sprint Planning;
30/10: 🌟 Sprint Review;
01/11: ⚙️ Sprint Retrospective;
01/11: 📝 entrega do relatório da sprint.

Sprint 4 | 30/10 a 20/11

30/10: 🗓 Sprint Planning;
20/11: 🌟 Sprint Review;
20/11: ⚙️ Sprint Retrospective;
20/11: 📝 entrega do relatório da sprint.

Encerramento | 22/11 a 11/12

22/11: 🌎 retrospectiva da AGES;
27/11: 🌎 apresentação dos projetos para todos os times;
02/12: one-on-one;
07/12: one-on-one.

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	Segundas e Quartas, 17:30 (início dos encontros síncronos)	15 minutos
Sprint Review	Demonstra-se, revisa-se e discute-se aquilo que foi trabalhado durante a Sprint, fornecendo inputs importantes para a Sprint Planning.	AGES IV	AGES I, II, III, IV e Cliente	Aproximadamente a cada 3 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 3 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 3 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 3 semanas (início da Sprint)	1 hora

Plano de riscos

Risco	Probabilidade	Impacto	Severidade	Estratégia	Ações
Alterações de escopo	1	5	20	Mitigar	Estabelecer o escopo no início do projeto e manter um equilíbrio, permitindo apenas alterações de menor impacto (que não demandem revisões extensas) ao longo do desenvolvimento.
Falta de engajamento de membros	3	5	20	Mitigar	Manter uma comunicação proativa e diálogos focados quando essas situações surgirem. Se houver um impacto significativo nos membros da equipe, ajustar a distribuição de tarefas conforme necessário.
Falta de entrega de User Stories planejadas	4	4	16	Mitigar	1.Supervisionar o progresso da equipe; se detectar qualquer potencial atraso, prestar assistência conforme requerido. 2. Estabelecer prazos de integração para tarefas, visando abordar tarefas pendentes de maneira eficaz.
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	Enviar lembretes com 6 horas de antecedência e manter canais de comunicação abertos e acessíveis com os stakeholders. Isso permite que fique sob a responsabilidade deles nos alertar com antecedência em caso de ausência necessária.
Entrega de User Stories planejadas antes do fim da sprint	3	5	15	Melhorar	Após concluir as entregas planejadas, avaliar a viabilidade de incluir mais User Stories (USs) dentro do escopo da nossa Sprint planejada.
AWS da AGES	5	4	20	Transferir	Orientar AGES III para se concentrarem no desenvolvimento do ambiente de homologação