Home | Escopo | Gerência | Processo | Mockups | Configuração | Arquitetura | DataBase | Infraestrutura |
---|
Descrição
Esta seção é dedicada a apresentar as responsabilidades de cada AGES, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.
Cronograma
Sprint | Data Início | Data Fim |
---|---|---|
Sprint 0 (warm up) | 07/08/2024 | 26/08/2024 |
Sprint 1 | 28/08/2024 | 11/09/2024 |
Sprint 2 | 16/09/2024 | 30/09/2024 |
Sprint 3 | 02/10/2024 | 30/10/2024 |
Sprint 4 | 04/11/2024 | 18/11/2024 |
EAP
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, 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. | Cliente | AGES I, II, III, IV e Cliente | Uma vez | 1 hora e 30 minutos |
Daily (aula meeting) | 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 | 20 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 | Ao final de cada sprint (A cada 2 ou 3 semanas) | 45 minutos |
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 | Ao final de cada sprint (A cada 2 ou 3 semanas) | 45 minutos |
Retrospectiva da Sprint | 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 | Ao final de cada sprint (A cada 2 ou 3 semanas) | 1 hora e 40 minutos |
Divisão de tarefas | Momento em que é realizada a divisão das User stories entre as squads. | AGES IV | AGES I, II, III, IV | Aproximadamente a cada 2 ou 3 semanas (início da Sprint) | 20 minutos |
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 | Ao fim da sprint, podendo manter as squads atuais | 30 minutos |
Plano de Recursos Humanos
Função por níveis
Ages | Responsáveis | Objetivo | Função | Artefatos |
---|---|---|---|---|
I | - Adrielle Dewes - Leonardo Simom - Lucca Muniz - Rafael Melo |
- Programação - Testes - Depuração |
- Desenvolver - código Auxiliar no desenvolvimento dos Mockups - Auxiliar na documentação da Wiki - Executar testes funcionais |
- Codigo desenvolvido e salvo no GIT - Relatorio das Sprints - Relatorio de Andamento - Relatorio Final |
II | - Eduardo Tavares - Fernanda Farias - Gabriel Severo - Giselle Chaves - Mariah Freire - Murilo Machado - Ruan Necker - Vitor Jacom |
- Analise de Requisitos - Projeto de Banco de Dados - Programação |
- Apoio a AGES I - Desenvolver código - Refatorar código |
- Fazer o levantamento dos Requisitos - Desenvolver e documentar o banco de dados (exemplo ER) - Toda a documentação técnica deve estar na Wiki |
III | - Andressa Farkas - Bruno Brandão - Lucas Barros |
- Testes e verificação - Projeto de software - Arquitetura de software |
- Apoio a AGES I e II - Desenvolver o setup para o projeto - Toda a documentação técnica deve estar na wiki |
- Segurança - Rotas de Backend (Arquitetura funcional) - Backend API - Arquitetura Não Funcional - Diagrama de Pacotes/Componentes (Arquitetura de Software) - Diagrama de Deploy - Documentação sobre aplicação de Design do Projeto - Analise dos principios SOLID - Code Review - Pagina na Wiki de Documentação - Relatorio das Sprints Andamento e Final |
IV | - Dylan Silveira - Leandro da Nóbrega - Nicolas Marques |
- Gerenciamento de Projetos - Aprofundamento de outras competências desenvolvidas no curso - Portfolio de conclusão de curso |
- Apoio a AGES I, II e III - Planejamento das Sprints - Criação das User Stories junto aos Stakeholders - Controle das tarefas do time (exemplo via trello) - Motivação do time - Controle do Processo da AGES - Desenvolvimento do Plano de Gestão do Projeto - Toda a documentação da gestão do projeto deve estar na Wiki |
- Termo de abertura (Atualização) - Identificação dos Stakeholders - EAP - User Stories - Cronograma - Plano de Comunicação - Plano de Recursos Humanos - Identificação dos Riscos - Plano de Respostas a Riscos - Pagina da Wiki de Documentação - Relatórios das Sprints, andamento e Final |
Identificação dos Riscos
Probabilidade | Impacto |
---|---|
0 até 10 da probabilidade de ocorrer algum risco | 0 até 10 onde mais próximo a 0 é menos prejudicial |
Risco | Tipo | Probabilidade | Impacto | Exposição |
---|---|---|---|---|
Falha na comunicação com as Stakeholders | Externo | 3 | 4 | 12 |
Falha na comunicação interna do time | Gerenciamento de Projeto | 4 | 5 | 20 |
Má divisão das tarefas | Gerenciamento de Projeto | 3 | 4 | 12 |
Problemas com as tecnologias/arquitetura | Técnico | 3 | 5 | 15 |
Problemas com a infraestrutura | Técnico | 3 | 5 | 15 |
Centralização de conhecimento | Gerenciamento de Projeto | 4 | 4 | 16 |
Redução do interesse do cliente | Gerenciamento de Projeto | 3 | 5 | 15 |
Desistência de integrantes do time | Gerenciamento de Projeto | 3 | 5 | 15 |
Plano de Respostas a Riscos
Risco | Estratégia | Ação | Responsáveis |
---|---|---|---|
Comunicação com as Stakeholders (clientes) | Mitigar | Sugerir uma possível outra forma de contato que a cliente utilize com maior frequência, sempre enfatizando a importância da participação dela nas decisões e entregas do time. | Professor e Ages IV (Whats). |
Comunicação interna do time | Mitigar | Manter os canais de comunicação, tanto em aula quanto fora, em funcionamento. | Ages IV |
Divisão de tarefas do time | Mitigar | Plannings organizadas/objetivas e histórias de usuário bem descritas e inseridas na ferramenta Trello, também garantir que todos os membros do time tenham tarefas a serem realizadas. | Ages IV |
Tecnologias escolhidas | Mitigar | Garantir que as tecnologias escolhidas sejam suficientes para o desenvolvimento do projeto e que o time inteiro as utilize seguindo boas práticas de desenvolvimento. | Ages III |
Modelagem de BD escolhida | Mitigar | Garantir que a modelagem do Banco de Dados esteja sendo seguida no desenvolvimento | Ages II |
Infraestrutura escolhida | Mitigar | Avaliar caminhos possiveis a seguir | Ages III |
Centralização de conhecimento | Mitigar | Incentivar a troca de informações entre o time. | Ages IV |
Padrões de Projeto | Mitigar | Alinhamento e definição para melhor modelo a seguir | Ages III |
Matriz de Responsabilidade
Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
Resumo das Siglas |
---|
P: Participa da atividade |
R: Responsável pela atividade |
C: Deve ser consultado |
I: Deve ser informado |
A: Aprova |
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 arquitetura | I | I | 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 |
Definir o git workflow | C | C | R | A |
Modelar o BD (conceitual/lógico) | I | R/A | R/A | A |
Desenvolvimento back/front | R | R | R | R |
Realização de Testes unitários | R | R | I | I |
Apresentação do Projeto | C | C | C | R |