Gerenciamento do Projeto
Histórico de revisão
| Data | Autor | Modificações | Versão |
|---|---|---|---|
| 23/02/2022 | Luís Lins | Cria documento de visão geral do projeto, unidade 2 | 1.0 |
| 01/03/2022 | Luís Lins, Kathlyn Lara | Atualizar planejamento das iterações do projeto, unidade 3 | 2.0 |
| 17/03/2022 | Luís Lins | Atualiza responsáveis dos papéis do Scrum | 2.1 |
| 01/04/2022 | Luís Lins | Cria documento para entrega da unidade 4, ajustando planejamento de iterações | 3.0 |
| 08/04/2022 | Luís Lins | Atualiza planejamento de iterações | 3.1 |
| 19/04/2022 | Luís Lins | Registra atraso no planejamento de iterações | 3.2 |
Organização do Projeto
| Papel | Atribuições | Responsáveis |
|---|---|---|
| Desenvolvedor | Codificar o produto, realizar refatorações, sugerir melhorias e alterações no produto | Ana Julia, Kathlyn Lara, Lais Portela, Luís Guilherme |
| Dono do Produto | Atualizar o escopo do produto, avaliar as atividades desenvolvidas ao longo da sprint, definir os critérios de aceitação das histórias de usuário, avaliar o andamento do projeto | Lais Portela |
| DevOps | Promover a padronização de desenvolvimento e a estabilidade do produto, garantir que o software é um artefato entregável, organizar o Github, o ZenHub, fazer o deploy da solução | Luís Guilherme |
| Mestre do Scrum | Orientar a equipe no desenvolvimento do projeto, garantindo que os membros sigam os valores e práticas da metodologia escolhida, controlar o nível de trabalho das sprints de acordo com o ritmo do time. Criar as issues, planejar as sprints junto da equipe, fazer as releases | Luís Guilherme |
Planejamento das Iterações do Projeto
| Entrega | Sprint | Produto (Entrega) | Data Início | Data Fim |
|---|---|---|---|---|
| OK | Sprint 1 | Criação da equipe | 24/01/2022 | 30/01/2022 |
| OK | Sprint 2 | Definição do produto, entrega da Unidade 1 (visão de produto, requisitos e metodologia) | 31/01/2022 | 06/02/2022 |
| OK | Sprint 3 | Correção da documentação pós-ponto de controle | 07/01/2022 | 13/02/2022 |
| OK | Sprint 4 | Organização do Repositório, construção do backlog do produto | 14/01/2022 | 20/02/2022 |
| OK | Sprint 5 | Melhorias do backlog do produto, levantamento do MVP, planejamento do Projeto, entrega da Unidade 2 | 21/02/2022 | 27/02/2022 |
| OK | Sprint 6 | Inicio do desenvolvimento, página inicial | 28/02/2022 | 06/03/2022 |
| OK | Sprint 7 | [FEAT01] - US01 | 07/03/2022 | 13/03/2022 |
| OK | Sprint 8 | [FEAT03] - US08 | 14/03/2022 | 20/03/2022 |
| OK | Sprint 9 | [FEAT04] - US10 | 21/03/2022 | 27/03/2022 |
| OK | Sprint 10 | [FEAT04] - US12 | 26/03/2022 | 01/04/2022 |
| OK | Sprint 11 | [FEAT05] - US15, US18 (Entrega do MVP 1 | 02/04/2022 | 08/04/2022 |
| ATRASADO | Sprint 12 | [FEAT05] - US16 | 09/04/2022 | 15/04/2022 |
| COMPENSADO | Sprint 13 | [FEAT06] US20, US21, [FEAT07] - US25 | 16/04/2022 | 22/04/2022 |
| - | Sprint 14 | US17, US19, (Entrega do MVP 2) | 23/04/2022 | 29/04/2022 |
Matriz de Comunicação
| Descrição | Envolvidos | Periodicidade | Artefatos Gerados |
|---|---|---|---|
| Scrum Daily | Equipe do projeto | Diária | Relatório falado do andamento da sprint |
| Sprint Review | Equipe do projeto | Semanal | Fechamento de Issues e PRs |
| Sprint Planning | Equipe do projeto | Semanal | Issues, atualização do cronograma |
| Comunicados e Dúvidas pelo Whatsapp | Equipe do projeto | Diária | - |
Gerenciamento de Riscos
Falta de domínio tecnológico
No caso de a equipe detectar que existe uma incapacidade de realizar as atividades do produto por conta de falta de conhecimento das tecnologias, será organizado um Dojô com uma demonstração prática da utilização delas. Além disso, o membro da equipe que apresentar essa dificuldade será colocado para parear com um outro membro que apresente um nível de conhecimento maior, a fim de transmitir esse conhecimento até que o primeiro ganhe certa autonomia.
Estouro de prazo devido a falhas de desenvolvimento
Na presença de bugs que a equipe não saiba resolver de forma rápida, a atividade que estava sendo desenvolvida será pausada em seu último estado estável e uma nova atividade será iniciada ou continuada, a fim de a equipe não perder tanto tempo e confiança diante de um problema.
Menor comprometimento por parte da equipe por conta de outros compromissos
Como todos os membros do time de desenvolvimento são universitários, haverá momentos em que as obrigações de outras disciplinas ou compromissos externos ocuparão mais tempo do que o previsto e com isso, menos tempo será dedicado para o desenvolvimento do produto. Diante disso, a cada Scrum Daily é perguntado para cada um se naquela sprint existe algum fator que comprometeria o desenvolvimento das atividades, a fim de prever momentos/dias em que o membro da equipe estaria indisponível, e com isso, adaptar a quantidade de trabalho daquela sprint.
Complexidade do sistema, não devidamente percebida nas etapas iniciais
A equipe de desenvolvimento não conhece a fundo as tecnologias a serem utilizadas, por isso existe a possiblidade de o time estar propondo o desenvolvimento de algo acima das suas capacidades. Caso isso ocorra, a tarefa em questão será simplificada, os critérios de aceitação serão revistos ou, em em último caso, a atividade em questão será descartada do backlog.