Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Globo Aplausos Wiki Globo Aplausos Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Globo Aplausos
  • Globo Aplausos WikiGlobo Aplausos Wiki
  • Wiki
  • gerencia

Last edited by Henrique Cardoso Zanette Nov 08, 2023
Page history

gerencia

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

Sumário

  • Estrutura Analítica do Projeto
  • Cronograma
  • Plano de comunicação
  • Plano de riscos
  • Retrospectiva
    • Sprint 0
    • Sprint 1
    • Sprint 2
    • Sprint 3
    • Sprint 4

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 Globo Aplausos, 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.

fluxograma-Page-1.drawio__1_

Gerenciamento das Tarefas

Em nosso ambiente de trabalho, buscamos constantemente maneiras de aprimorar nossa eficiência e produtividade na gestão de projetos. Uma ferramenta que se destacou como essencial em nossa abordagem é o Trello. O Trello é uma plataforma intuitiva de gerenciamento de projetos baseada em quadros virtuais e cartões. Na essência, ele funciona como um quadro de tarefas virtual que nos permite visualizar e monitorar o progresso das tarefas de nossa equipe de forma transparente.

Utilizando Etiquetas para Organização Precisa

Uma das características que fazem do Trello uma ferramenta tão valiosa para nós é a capacidade de adicionar etiquetas personalizadas aos nossos cartões de tarefas. Estas etiquetas são uma parte fundamental da nossa metodologia de organização. Vejamos como as utilizamos:

  1. Número da US ou Task: Atribuímos um número de identificação único a cada tarefa. Isso simplifica a identificação das tarefas, especialmente em projetos complexos com muitas atividades em andamento.

  2. Tipo de Tarefa (Backend, Frontend, Documentação, Arquitetura, Testes): Categorizamos nossas tarefas por tipo. Dessa forma, sabemos quais membros da equipe são mais adequados para executar cada tipo de tarefa, tornando a alocação de recursos mais eficiente.

  3. Épico da User Story (US): Associamos cada tarefa a um épico específico relacionado à história do usuário. Isso nos ajuda a manter uma visão clara dos objetivos de longo prazo do projeto e a entender como cada tarefa se encaixa nesse contexto mais amplo.

Captura_de_Tela_2023-09-20_às_21.03.14

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.

  • 📑 Dowloand Cronograma

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;
  • 04/09: 🗓 SI Day;
  • 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;
  • 29/11: one-on-one;
  • 04/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 invite para o email do cliente para serem colocados na agenda com bastante antecedência, além disso enviar uma mensagem 2 dias antes para confirmar a presença.
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

Retrospectiva

A retrospectiva é um ponto crucial no ciclo ágil, onde a equipe se reúne para avaliar o passado e planejar melhorias para o futuro. É um espaço de reflexão e aprendizado contínuo, permitindo que o time identifique o que está funcionando bem e o que pode ser aprimorado, resultando em um crescimento constante e uma colaboração mais eficaz.

Tabela de Plano de Ação: A tabela de plano de ação é uma ferramenta usada durante a retrospectiva para registrar as medidas a serem tomadas com base nas conclusões da equipe. Ela ajuda a acompanhar as ações necessárias para resolver problemas e otimizar processos. A tabela destaca cada tarefa a ser realizada após a retrospectiva. O "Responsável" é a pessoa encarregada de liderar essa tarefa, e “Status” indica se a tarefa foi concluída ou não.

Legenda para planos de ação

  • ✅ :realizado
  • ⚠ : iniciado mas não finalizado
  • ❌ : não realizado

Sprint 0

fluxograma-Page-1.drawio
Item de Ação Responsável Status
Bot do GitLab AGES IV ✅
Adicionar conteúdos de Frontend Time ✅
Avisar quando for entrar para desenvolver Time ✅
Documentar os padrões de projeto AGES III ✅

Sprint 1

fluxograma-Page-1.drawio__1_
Item de Ação Responsável Status
Melhores Práticas AGES I Arthur e André ✅
Melhores Práticas AGES II Thomas e David ✅
Melhores Práticas AGES III AGES III ⚠
Melhores Práticas AGES IV AGES IV ✅
Criar Canal Urgência Discord AGES IV ✅
Inserir Imagem nos MRs do Frontend Time ✅
Melhorar Documentação do Banco na Wiki AGES II ✅
Melhorar Documentação da Arquitetura na Wiki AGES III ✅
Explicar como preencher o modelo de MR AGES III ✅
Inserir Testes Automatizados de Interface AGES III ✅

Sprint 2

fluxograma-Page-1.drawio
Item de Ação Responsável Status
Padronizar DTO no Backend AGES III
Tirar Imagem Aleatória no Card Usuário Time ✅
Adicionar mais informações Wiki desenvolvimento AGES III ✅

Sprint 3

fluxograma-Page-1.drawio

Sprint 4

fluxograma-Page-1.drawio
Clone repository
  • Analytics
  • Arquitetura
  • Backend
  • Banco de Dados
  • Codigo
  • Configuracao
  • Design_Mockups
  • Escopo
  • Frontend
  • Processo
  • Qualidade
  • gerencia
  • Home