Visão geral do projeto
Histórico de revisão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 14/11/2022 | 0.1 | Criação e estruturação do documento | Lucas Queiroz |
| 16/11/2022 | 0.2 | Alterações no documento | Arthur Trindade Gabriel de Souza Lucas Queiroz Miguel Moreira |
| 07/11/2022 | 0.3 | Atualizações da unidade 2 | Arthur Trindade |
| 05/01/2023 | 0.4 | Atualizações da unidade 3 | Miguel Moreira |
| 08/01/2023 | 0.5 | Atualizações da unidade 4 | Miguel Moreira |
Organização do projeto
| Papel | Atribuições | Responsável | Participantes |
|---|---|---|---|
| Desenvolvedor | Programar a aplicação; Escrever a documentação do software; Realizar testes. |
Gabriel de Souza | Arthur D'Assumpção Arthur Trindade Gabriel de Souza Miguel Moreira |
| Scrum Master | Garantir que os processos relativos ao Scrum ocorram de maneira funcional. | Papel rotativo | Arthur D'Arthur D'Assumpção Arthur Trindade Gabriel de Souza Miguel Moreira |
| Product Owner | Desenvolver e comunicar, explicitamente, os objetivos do produto; Criar e comunicar os itens do backlog do produto; Garantir a compreensão do backlog do produto. |
Arthur D'Assumpção | Arthur D'Assumpção |
| Designer | Planejar o layout das interfaces do site. | Miguel Moreira | Arthur D'Assumpção Arthur Trindade Gabriel de Souza Miguel Moreira |
| Cliente | Dar feedback do projeto à equipe de desenvolvimento; Validar os protótipos e entregas; |
Arthur D'Assumpção | Zenit Aerospace |
Planejamento das Fases e/ou Iterações do Projeto
| Sprint | Atividades | Produto (Entrega) | Data Início | Data fim |
|---|---|---|---|---|
| 1 | Definição do produto; Inicio da documentação. |
Ideia inicial do produto; Documento de visão de produto. |
27/10/2022 | 01/11/2022 |
| 2 | Revisão do documento de visão de produto; Construção do GitPages. |
GitPages; Documento de visão de produto atualizado. |
02/11/2022 | 10/11/2022 |
| 3 | Desenvolvimento do documento de visão de projeto. | Documento de visão de projeto. | 11/11/2022 | 17/11/2022 |
| 4 | Reunião 1 com o cliente | Lista de de requisitos iniciais do produto. | 18/11/2022 | 24/11/2022 |
| 5 | Reunião 2 com o cliente; Refinamento da lista de requisitos; Construção da estrutura inical do projeto. |
Lista de requisitos do projeto; Estrutura inicial do projeto (Épicos, Features e US's) |
25/11/2022 | 01/12/2022 |
| 6 | Reconstrução da estrutura do projeto; Desenvolvimento das estratégias de refatoração e TDD; Revisão da visão de projeto. |
Documentação atualizada; Estrutura do projeto (Épicos, features e US's) |
02/12/2022 | 08/12/2022 |
| 7 | Desenvolvimento | 20/12/2022 | 27/12/2022 | |
| 8 | Desenvolvimento | E1-F1-US1 |
28/12/2022 | 04/12/2022 |
| 9 | Desenvolvimento; Reunião de validação com o cliente; Atualização da documentação. |
E1-F1-US1 E1-F1-US2 E1-F2-US1 E1-F2-US2 E1-F2-US3 E2-F1-US1 E2-F1-US2 E2-F1-US3 Entrega do MVP1. |
05/01/2023 | 12/01/2023 |
| 10 | Desenvolvimento; Refatoração; |
E1-F2-US2 E1-F2-US3 E2-F1-US1 E2-F1-US2 E2-F1-US E3-F1-US4 E4-F2-US1 Backlog do produto atualizado. |
17/01/2023 | 24/01/2023 |
| 11 | Desenvolvimento; Refatoração; Atualização da documentação; |
E3-F1-US2 E3-F1-US3 E3-F1-US4 E3-F1-US5 E3-F2-US1 Código corrigido; GitPages atualizado. |
25/01/2023 | 01/02/2023 |
| 12 | Desenvolvimento; Reunião de validação com o cliente; Atualização da documentação. |
E3-F1-US1 E3-F2-US2 E3-F2-US3 E4-F1-US1 E4-F1-US2 E4-F2-US2 Entrega do MVP2. |
02/02/2023 | 09/02/2023 |
Matriz de Comunicação
| Descrição | Área/Envolvidos | Periodicidade | Produtos Gerados |
|---|---|---|---|
| Planejamento da sprint | Equipe de desenvolvimento | Semanal | Backlog da sprint. |
| Daily Scrum | Equipe de desenvolvimento | Diária | Revisão do pregresso das atividades. |
| Sprints | Equipe de desenvolvimento | Semanal | Incremento de valor. |
| Revisão e retrospectiva da sprint | Equipe de desenvolvimento | Semanal | Revisão dos resultados da sprint atual; Planejamento da próxima sprint. |
| Comunicar situação do projeto | Equipe de desenvolvimento George Marsicano |
Semanal | Feedback do professor Atualização da documentação do projeto. |
Gerenciamento de riscos
Gerenciar riscos é particularmente importante para projetos de software por conta das incertezas inerentes que a maioria dos projetos enfrenta. Elas se originam de requisitos vagamente definidos, mudanças de requisitos devido a mudanças nas necessidades do cliente, dificuldades em estimar o tempo e os recursos necessários para o desenvolvimento do software e diferenças nas habilidades individuais. É preciso prever os riscos, compreender o impacto desses riscos sobre o projeto, o produto e o negócio e tomar medidas para evitar tais riscos.
Dito isso, a equipe decidiu considerar os seguintes riscos:
| Descrição | Causa | Probabilidade | Mitigação |
|---|---|---|---|
| Redução da equipe | Trancamento da disciplina ou qualquer questão pessoal dos membros que impossibilite a realização permanente ou temporária das atividades de desenvolvimento. | Baixa | Compensar por aumento na carga horária de trabalho dos membros restantes. |
| Falha na comunicação externa | Falta de comunicação com o cliente por indisponibilidade do mesmo ou perda de contato. | Baixa | Buscar contatos de membros de outros núcleos de gestão da Zenit. |
| Falha na comunicação interna | Falta de comunicação entre os membros da equipe que possam levar a uma conclusão equivocada ou por questões como falta de internet ou energia. | Média | Repensar a metodologia de comunicação e redistribuir temporariamente as atividades. |
| Atraso do cronograma | Falta de competência da equipe de desenvolvimento com as ferramentas propostas. | Média | Promover treinamentos para a equipe nas ferramentas em questão. |
| Dimensão do projeto | Escopo de projeto muito grande para ser desenvolvido no tempo da disciplina com as competências dos membros | Média | Redefinir o escopo do produto. |
| Desvio de foco | Conflito de responsabilidades da equipe com faculdade, trabalho, família e etc ou falta de motivação dos membros. | Alta | Comunicação frequente entre os membros da equipe. |
| Enfermidades | Incapacitação dos desenvolvedores por questões de saúde. | Altíssima | Compensar por aumento na carga horária de trabalho dos membros restantes. |
Critérios de replanejamento
- Trancamento da disciplina por membros da equipe;
- Escopo maior que o esperado para o desenvolvimento dentro do tempo disponível;
- Atraso na entrega do MPV1.
Bibliografia
- Sommerville, I., Engenharia de software. 9th ed., Pearson Addison Wesley, 2011.