Visão Geral do Projeto
Historico de Revisão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 16/04/2023 | 0.1 | Criação do gitpages, adição do visão geral do produto e do projeto | Arthur, Eric, Pedro Lucas, Yasmim |
| 18/04/2023 | 0.2 | Topicos 1-4 finalizados temporáriamente | Arthur, Eric, Pedro Lucas |
| 22/06/2023 | 0.3 | Alteração data das sprints | Pedro Lucas |
| 23/06/2023 | 0.4 | Detalhamento dos Produtos e Entregas de cada sprint | Pedro Lucas |
| 08/06/2023 | 0.5 | Atualização iterações do projeto | Pedro Lucas |
1 - Organização do Projeto
| Papel | Atribuições | Responsável | Participantes |
|---|---|---|---|
| DEV Ci-Test | Automatiza o processo de integração, contribui para compilar e construir o software, integra o código-fonte, realiza análises estáticas e testes, gera relatórios e fornece feedback imediato aos desenvolvedores. | Yasmim | Arthur, Dara, Eric, Fábio e Pedro Lucas |
| DEV Front end | Desenvolve as interfaces de usuário e layouts intuitivos, otimiza a performance e usabilidade, testa a compatibilidade em diferentes navegadores dispositivos e tamanhos de telas. | Eric e Fábio | Arthur, Dara, Pedro Lucas e Yasmim. |
| DEV Back end | Trabalha com as lógicas de negócio, armazenamento e recuperação de dados, autenticação, segurança, integração com outros sistemas, desenvolve APIs, bancos de dados e realiza testes de desempenho e escalabilidade. | Dara e Arthur | Eric, Fábio, Pedro Lucas e Yasmim. |
| DEV Master | Lidera a equipe de desenvolvimento, fornece orientação técnica, garante a qualidade do código, arquiteta soluções e sistemas complexos e participa da tomada de decisões estratégicas para o desenvolvimento do software. | Pedro Lucas | Arthur, Dara, Eric, Fábio e Yasmim. |
| Cliente | Define as necessidades e requisitos do produto, valida o software, prioriza o backlog juntamente com a equipe, participa de algumas reuniões e aprova o software final. O seu feedback e validação são fundamentais para garantir que o software atenda às suas expectativas e necessidades, bem como para orientar o processo de desenvolvimento. | Giulia Alcantara | Arthur, Dara, Eric, Fábio Pedro Lucas e Yasmim. |
2 - Planejamento das Fases e/ou Iterações do Projeto
| MVP1 | Produto(Entrega) | Data Início | Data Fim |
|---|---|---|---|
| Sprint 1 | Definição duração Sprint Mudança do banco de dados Mudança de Framework Alteração no codigo para ficar funcional Refatoração de Código |
01/05 | 15/05 |
| Sprint 2 | T04-EP10-US38 T04-EP11-US44 |
16/05 | 31/05 |
| Sprint 3 | MVP1 T04-EP10-US37 T04-EP10-US39 T02-EP04-US17 T03-EP08-US33 T03-EP08-US34 |
01/06 | 15/06 |
| MVP2 | Produto(Entrega) | Data Início | Data Fim |
|---|---|---|---|
| Sprint 4 | T04-EP11-US45 T04-EP11-US47 | 19/06 | 04/07 |
| Sprint 5 | T02-EP04-US18 T02-EP04-US19 T04-EP11-US45 T04-EP11-US46 T05-EP12-US48 T05-EP12-US49 T05-EP12-US50 T05-EP12-US51 | 05/07 | 20/07 |
3 - Matriz de Comunicação
| Descrição | Área/Envolvidos | Periodicidade | Produtos Gerados |
|---|---|---|---|
| - Sprint planning | Time Scrum, Scrum Master e Product Owner | De 15 em 15 dias, tendo no máximo 2 horas de duração | Definição e organização do Backlog da Sprint. |
| - Adaptação do daily Scrum | Scrum Master e Time de desenvolvimento | Todos os dias a partir das 18:00 | Breve esclarecimento das atividades desempenhadas individualmente naquele dia. |
| - Sprint review | Scrum Master, Time Scrum e Stakeholders | De 15 em 15 dias, tendo no máximo 1 hora de duração | Apresentação dos resultados da sprint e recebimento de feedbacks. |
| - Sprint retrospective | Scrum Master, Time de desenvolvimento e Product Owner | De 15 em 15 dias, tendo duração máxima de 1 hora | Analisa os processos da sprint, propõem ajuste na questão de eficiência e padrões, para melhorias na próxima sprint. |
4 - Gerenciamento de riscos
| Lista de Riscos | Estratégias para redução de riscos | Escala qualitativa (baixa, média, alta) |
|---|---|---|
| - Atrasos no cronograma | Utilização de metodologias ágeis, que enfatizam a comunicação frequente, o planejamento flexível e a entrega incremental de funcionalidades. Definição clara de metas e prazos realistas, ferramentas de gestão de projetos e a priorização de tarefas. | Alta |
| - Mudanças frequentes no escopo | Definir claramente o backlog, estabelecer um processo organizado para o gerenciamento de mudanças de forma realista e transparente, identificar e priorizar requisitos, se comunicar claramente com o cliente, fornecer entregas frequentes. | Alta |
| - Ausência de experiência técnica | Investir em capacitações técnicas, aprender com a comunidade de desenvolvimento de software, investir em prototipagem e testes, se concentrar em tecnologias familiares, manter o estudo constante e ir em busca de conhecimento. | Baixa |
| - Limitações de comunicação com o cliente | Estabelecer um ponto de contato único, utilizar ferramentas de comunicação, documentar o processo de desenvolvimento, adotar uma abordagem iterativa, utilizar protótipos e mockups e contratar um intermediário para atuar como canal de comunicação. | Baixa |
| - Documentação abstrata | Revisões de código, adoção de metodologias ágeis, uso de ferramentas de testes, utilização de diagramas e fluxogramas, criação de protótipos e mockups, estabelecimento de um glossário de termos e comunicação frequente com o cliente. | Baixa |
| - Problemas com performance e qualidade do produto | Identificar e priorizar os problemas, refatorar e otimizar todo o código e suas propriedades, adotar boas práticas de desenvolvimento, utilizar ferramentas de monitoramento, adotar uma mentalidade de melhoria contínua e manter um padrão de qualidade em busca da excelência do produto. | Média |
| - Falhas no controle de qualidade e testes | Identificar e priorizar as falhas, revisar processos, automatizar testes, estabelecer padrões de qualidade, adotar boas práticas de desenvolvimento, capacitar a equipe, manter comunicação com usuários e stakeholders. | Alta |
| - Falta de comprometimento da equipe | Objetivos claros, motivar a equipe, definir papéis e responsabilidades, encorajar a colaboração, estabelecer um plano de ação, oferecer suporte e recursos e manter uma comunicação aberta e transparente com a equipe. | Média |
| - Concentração excessiva em uma única área resultando na não conclusão do produto completo do backlog. | Monitoramento constante, estabelecer uma exata definição de pronto, garantir a eficácia, eficiência, suporte e revisões, buscar expandir o conhecimento e entregar algo de qualidade e funcional. | Alta |
5 - Critérios de replanejamento
- Atrasos no cronograma;
- Alterações na equipe de trabalho;
- Riscos identificados que afetam o projeto;
- Mudanças no escopo do projeto;
- Mudanças nos requisitos do cliente ou dos stakeholders;
- Mudanças na tecnologia ou na infraestrutura do projeto;
- Problemas de comunicação ou colaboração entre as partes interessadas;
- Problemas técnicos que afetam o desenvolvimento do software;
- Problemas de qualidade do produto ou do processo de desenvolvimento.