Tabela 1 - Organização do Projeto
-| Perfil | Atribuições | Responsável | Participantes | -|---|---|---|---| -| Líder/Scrum Master | Assegurar que a equipe siga os princípios e métodos do Scrum. | [Luciano Freitas](https://github.com/luciano-freitas-melo) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Pablo Santos](https://github.com/pabloheika), [Victorio Lazaro](https://github.com/Victor-oss) e [Weslley Barros](https://github.com/weslley17w) | -| Product Owner | Responsável por definir e priorizar o backlog de produto, representando as necessidades do cliente e otimizando o valor entregue. | [Pablo Santos](https://github.com/pabloheika) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Luciano Freitas](https://github.com/luciano-freitas-melo), [Victorio Lazaro](https://github.com/Victor-oss) e [Weslley Barros](https://github.com/weslley17w) | -| Desenvolvedores | Responsável por projetar, codificar e testar funcionalidades, trabalhando juntos para alcançar metas da equipe Scrum. | [Weslley Barros](https://github.com/weslley17w) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Luciano Freitas](https://github.com/luciano-freitas-melo), [Pablo Santos](https://github.com/pabloheika) e [Victorio Lazaro](https://github.com/Victor-oss) | -| Cliente | Responsável por fornece informações sobre requisitos e expectativas, garantindo que o produto atenda às suas necessidades. | Mateus | Mateus | -| Monitor | Responsável por retirar dúvidas, oferecer opiniões, acompanhar e, se necessário, ajudar a equipe para garantir a entrega de um bom trabalho. | João Matheus | João Matheus | +| Perfil | Atribuições | Responsável | Participantes | +| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Líder/Scrum Master | Assegurar que a equipe siga os princípios e métodos do Scrum. | [Luciano Freitas](https://github.com/luciano-freitas-melo) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Pablo Santos](https://github.com/pabloheika), [Victorio Lazaro](https://github.com/Victor-oss) e [Weslley Barros](https://github.com/weslley17w) | +| Product Owner | Responsável por definir e priorizar o backlog de produto, representando as necessidades do cliente e otimizando o valor entregue. | [Pablo Santos](https://github.com/pabloheika) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Luciano Freitas](https://github.com/luciano-freitas-melo), [Victorio Lazaro](https://github.com/Victor-oss) e [Weslley Barros](https://github.com/weslley17w) | +| Desenvolvedores | Responsável por projetar, codificar e testar funcionalidades, trabalhando juntos para alcançar metas da equipe Scrum. | [Weslley Barros](https://github.com/weslley17w) | [Artur Rodrigues](https://github.com/ArturRSA19), [João Barreto](https://github.com/JoaoBarreto03), [Luciano Freitas](https://github.com/luciano-freitas-melo), [Pablo Santos](https://github.com/pabloheika) e [Victorio Lazaro](https://github.com/Victor-oss) | +| Cliente | Responsável por fornece informações sobre requisitos e expectativas, garantindo que o produto atenda às suas necessidades. | Mateus | Mateus | +| Monitor | Responsável por retirar dúvidas, oferecer opiniões, acompanhar e, se necessário, ajudar a equipe para garantir a entrega de um bom trabalho. | João Matheus | João Matheus |Fonte: Autores (2023)
## Planejamento das Fases e/ou Iterações do Projeto @@ -32,52 +33,60 @@ *A tabela 2 apresenta um resumo das sprints e entregas relacionadas ao nosso projeto. As informações incluem o número da sprint, o nome da entrega associada, a data de início da sprint e a data de conclusão da sprint. Utilize esta tabela para acompanhar o progresso do projeto e garantir que todas as tarefas sejam concluídas dentro do prazo estabelecido.*Tabela 2 - Cronograma do Projeto
-| Sprint | Entrega | Data de início | Data de fim | -|---|---|---|---| -| Sprint 0 | Definição do produto e entrega da Visão do Produto e Projeto | 15/09/2023 | 27/09/2023 | -| Sprint 1 | Configuração do ambiente de desenvolvimento, nivelamento da equipe, definição do backlog, definição de user stories, definição de arquitetura, definição de MVP | 30/09/2023 | 11/10/2023 | -| Sprint 2 | Sistema de autenticação do sistema (Login e Registro), definição de Backlog SAFe e entrega da Missão 2 (26/10) | 14/10/2023 | 25/10/2023 | -| Sprint 3 | Funcionalidade de criação dos drills | 28/10/2023 | 08/11/2023 | -| Sprint 4 | Funcionalidade de criação dos drills | 11/11/2023 | 22/11/2023 | -| Sprint 5 | Definição de Backlog com PBB, definição situações de comportamento para cada User Story com o BDD, Entrega Missão 3 (23/11), funcionalidade de gestão das quadras e testes | 25/11/2023 | 06/12/2023 | -| Sprint 6 | Diagrama e especificação de casos de uso, Entrega Missão 4 (14/12) | 09/12/2023 | 20/12/2023 | +| Sprint | Entrega | Data de início | Data de fim | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ----------- | +| Sprint 0 | Definição do produto e entrega da Visão do Produto e Projeto | 15/09/2023 | 27/09/2023 | +| Sprint 1 | Configuração do ambiente de desenvolvimento, nivelamento da equipe, definição do backlog, definição de user stories, definição de arquitetura, definição de MVP | 30/09/2023 | 11/10/2023 | +| Sprint 2 | Sistema de autenticação do sistema (Login e Registro), definição de Backlog SAFe e entrega da Missão 2 (26/10) | 14/10/2023 | 25/10/2023 | +| Sprint 3 | Funcionalidade de criação dos drills | 28/10/2023 | 08/11/2023 | +| Sprint 4 | Funcionalidade de criação dos drills | 11/11/2023 | 22/11/2023 | +| Sprint 5 | Definição de Backlog com PBB, definição situações de comportamento para cada User Story com o BDD, Entrega Missão 3 (23/11), funcionalidade de gestão das quadras e testes | 25/11/2023 | 06/12/2023 | +| Sprint 6 | Diagrama e especificação de casos de uso, Entrega Missão 4 (14/12) | 09/12/2023 | 20/12/2023 |Fonte: Autores (2023)
## Matriz de Comunicação -*Esta seção descreve a estratégia de comunicação adotada para monitoramento do progresso do projeto como mostrado na tabela 3. Identificar a periodicidade de reuniões e o envio dos relatórios exigidos pelo processo e opcionalmente outros relatórios exigidos pelo cliente.* +*A matriz de comunicação tem por objetivo auxiliar a equipe na organização da execução do projeto, uma vez que ela consiste em definir quais informações serão compartilhadas, as pessoas que as receberão e a frequência em que essa comunicação ocorrerá, como é mencionado no PMBOK (2017)¹.* + +*Esta seção descreve a estratégia de comunicação adotada para monitoramento do progresso do projeto como mostrado na tabela 3.*Tabela 3 - Matriz de Comunicação
| **Descrição** | **Área/Envolvidos** | **Periodicidade** | **Produtos Gerados** | -|-------------------------------|------------------------------|-------------------|---------------------------------------------------------------------------------------------------------------------| -| Planejamento das atividades | Equipe do projeto | Quinzenal | Planejamento do que será feito no ciclo da sprint | +| ----------------------------- | ---------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------- | +| Planejamento das atividades | Equipe do projeto | Quinzenal | Planejamento do que será feito no ciclo da sprint | | Acompanhamento das atividades | Equipe do projeto | Diário | Relato por parte dos membros da equipe no whatsapp ou no discord sobre o andamento individual das partes do projeto | -| Revisão das atividades | Equipe do projeto, cliente | Quinzenal | Validação do produto | +| Encontro com o cliente | Product owner, cliente | Quinzenal | Validação do produto | | Retrospectiva das atividades | Equipe do projeto | Quinzenal | Identificação de oportunidades de melhoria | -| Comunicar situação do projeto | Equipe do projeto, professor | Quinzenal | Artefatos solicitados e relação de feedbacks do professor | +| Comunicar situação do projeto | Equipe do projeto, professor | Quinzenal | Artefatos solicitados e relação de feedbacks do professor |Fonte: Autores (2023)
## Gerenciamento de Riscos -*De acordo com o PMBOK (2017)¹, risco é um evento ou condição que pode ter impacto positivo ou negativo em um projeto de software, podendo levar a atrasos ou prejuízos. Portanto, o gerenciamento de risco é crucial para garantir o sucesso do projeto, os tópicos abaixo trazem informações sobre os principais riscos do projeto e as ações para mitigá-los.* +*De acordo com o PMBOK (2017)¹, risco é um evento ou condição que pode ter impacto positivo ou negativo em um projeto de software, podendo levar a atrasos ou prejuízos. Portanto, o gerenciamento de risco é crucial para garantir o sucesso do projeto, a tabela 4 abaixo traz informações sobre os principais riscos do projeto e as ações para mitigá-los.* + +Tabela 4 - Gerenciamento de Riscos
-- **Atraso nas entregas**: Baixa produtividade dos membros da equipe e/ou dimensionamento incorreto do escopo da iteração e dos MVPs. -- **Abandono do projeto**: A equipe pode tomar medidas para minimizar as chances de abandono do projeto, como a realocação de responsabilidades e a diminuição no escopo. -- **Abandono da disciplina por parte dos integrantes**: É importante garantir que haja uma comunicação clara e aberta entre a equipe e que as expectativas sejam estabelecidas e comunicadas claramente. Isso pode ajudar a minimizar o abandono da disciplina, pois os membros da equipe entenderão as expectativas esperadas para o projeto. -- **Comunicação Ineficiente entre stakeholders**: A falta de comunicação clara e efetiva entre os stakeholders pode levar a perda ou má interpretação de informações importantes. Isso pode causar atrasos e custos adicionais no projeto. -- **Comunicação ineficiente entre os integrantes da equipe**: Quando a comunicação não é efetiva, a equipe pode ter dificuldades em colaborar, alcançar seus objetivos e atender às expectativas do cliente. -- **Sobrecarga de trabalho de membros da equipe**: É importante que o gerente do projeto defina claramente as responsabilidades de cada membro da equipe. Isso ajuda a evitar situações em que uma pessoa é sobrecarregada com tarefas que não são de sua responsabilidade. -- **Inviabilidade de um requisito**: Requisitos que não podem ser implementados por questões técnicas ou de negócio. +| Tipos de Risco | Descrição | Probabilidade | Mitigação | +| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Risco de problemas de saúde | Em algum momento, algum dos integrantes pode ter que se afastar devido a problemas de saúde, o que prejudicaria o desenvolvimento do projeto. | Média | - Os demais membros da equipe podem repartir as funções que seria(m) exercida(s) pelo(s) membro(s) ausente(s), devido a existência de algum problema desse tipo. | +| Risco de abandono | A equipe pode não querer continuar o trabalho e abandoná-lo, devido à sua complexidade ou algum membro pode desistir da disciplina. | Média | - Diminuição do espoco do projeto e realocação de responsabilidades da equipe.Fonte: Autores (2023)
## Critérios de Replanejamento *São condições que podem ocorrer durante o projeto que exijam uma revisão e adaptação do planejamento original. Deve ser feito o acompanhamento desses critérios a cada sprint, garantindo a qualidade do projeto até sua finalização.* +- **Mudanças significativas no cronograma**: O prazo para a entrega do projeto pode ser alterado, afetando o planejamento realizado inicialmente. Para isso, é importante que a equipe seja capaz de mensurar quais partes do projeto podem ser entregues com esse novo cronograma. - **Alteração nos requisitos**: Pode ser que ao longo do projeto surjam novas necessidades, diante disso, é importante que a equipe esteja preparada para lidar com essas alterações, avaliando seus impactos e definindo um plano adequado. - **Riscos não previstos**: Mesmo com um planejamento bem feito, sempre existe a possibilidade de que riscos não previstos ocorram durante o projeto. A equipe deve estar preparada para identificar esses riscos e definir um plano de ação para amenizá-los. - **Atrasos**: É importante que o planejamento do projeto seja realista e que a equipe trabalhe dentro dos prazo e metas estabelecidos, trabalhando de forma colaborativa visando maximizar a produtividade. -- **Alteração no cronograma**: Pode ser que com a saída de algum membro da equipe seja necessário revisar o cronograma e redistribuir a carga de trabalho entre os outros membros para efetuar a entrega no prazo estabelecido -- **Alteração no backlog**: Caso a comunicação com o cliente seja ineficiente e o cliente se sinta insatisfeito com os entregáveis apresentados pela equipe, é necessário marcar reuniões com o cliente para que a equipe alinhe sua visão do projeto com a do cliente e altere o backlog caso necessário +- **Alteração no backlog**: Caso a comunicação com o cliente seja ineficiente e o cliente se sinta insatisfeito com os entregáveis apresentados pela equipe, é necessário marcar reuniões com o cliente para que a equipe alinhe sua visão do projeto com a do cliente e altere o backlog caso necessário. +- **Problemas com a qualidade**: Pode ser que aplicação desenvolvida contenha erros que passaram despercebidos no teste ou algum problema de usabilidade que poderia ser corrigido. Assim, a equipe deverá replanejar suas atividades, reconhecer os erros/problemas e elaborar uma nova solução ## Referências Bibliográficas