Merge pull request #61 from mdsreq-fga-unb/entrega3_final

Alterações finais para entrega 3
mdsreq-fga-unb · Nov 23, 2023 · 75e388c · 75e388c
2 parents df0b8a8 + 6ffc410
commit 75e388c
Show file tree

Hide file tree

Showing 25 changed files with 236 additions and 73 deletions.
diff --git a/docs/assets/GBL_DOR&DOD.png b/docs/assets/GBL_DOR&DOD.png
diff --git a/docs/assets/VV_crit/crit_1.png b/docs/assets/VV_crit/crit_1.png
diff --git a/docs/assets/VV_crit/crit_2.png b/docs/assets/VV_crit/crit_2.png
diff --git a/docs/assets/VV_crit/crit_3.png b/docs/assets/VV_crit/crit_3.png
diff --git a/docs/assets/VV_crit/crit_4.png b/docs/assets/VV_crit/crit_4.png
diff --git a/docs/assets/VV_crit/crit_5.png b/docs/assets/VV_crit/crit_5.png
diff --git a/docs/assets/VV_crit/crit_6.png b/docs/assets/VV_crit/crit_6.png
diff --git a/docs/assets/VV_crit/crit_7.png b/docs/assets/VV_crit/crit_7.png
diff --git a/docs/assets/VV_crit/crit_8.png b/docs/assets/VV_crit/crit_8.png
diff --git a/docs/assets/VV_crit/crit_9.png b/docs/assets/VV_crit/crit_9.png
diff --git a/docs/doc-visao/2.visao-projeto.md b/docs/doc-visao/2.visao-projeto.md
@@ -48,11 +48,11 @@
 | Sprint 6 | Priorização das US's e definição do MVP  | 15/10/2023       | 21/10/2023  |
 | Sprint 7 | Validação do Backlog SAFE do Produto       | 22/10/2023    | 28/10/2023  |
 | Sprint 8 | Refatoração e validação do MVP      | 29/10/2023     | 04/11/2023  |
-| Sprint 9 | Definição dos critérios de DOR e DOD       | 05/11/2023     | 11/11/2023  |
-| Sprint 10 | US01, US02              | 12/11/2023     | 18/11/2023  |
-| Sprint 11 | US49, US50, US51, US52 | 19/11/2023     | 25/11/2023  |
-| Sprint 12 |  US54, US57, US58, US60 | 26/11/2023     | 02/12/2023  |
-| Sprint 13 | US61, US53, US55, US56  | 03/12/2023     | 09/12/2023  |
+| Sprint 9 | Definição dos critérios de aceitação das histórias       | 05/11/2023     | 11/11/2023  |
+| Sprint 10 | Definição dos critérios de DOR e DOD              | 12/11/2023     | 18/11/2023  |
+| Sprint 11 | US01, US02, US49, US50 | 19/11/2023     | 25/11/2023  |
+| Sprint 12 |  US51, US52, US54, US57, US58 | 26/11/2023     | 02/12/2023  |
+| Sprint 13 | US60, US61, US53, US55, US56  | 03/12/2023     | 09/12/2023  |
 <p style="display: flex; justify-content: center; font-size: 0.8em">Fonte: Autores (2023)</p>
 
 ## Matriz de Comunicação

diff --git a/docs/doc-visao/3.processo-dev.md b/docs/doc-visao/3.processo-dev.md
@@ -100,7 +100,7 @@
 <p style="display: flex; justify-content: center; font-size: 0.8em">Tabela 1 - Características do Scrum a serem trabalhadas no projeto</p>
 | **Rituais/Artefatos**    | **Descrição**                                                                                                                                                                                                                |
 |:------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
-| Sprints                  | As sprints terão duração de 1 semanas, sempre iniciando e finalizando aos sábados.                                                                                                                          |
+| Sprints                  | As sprints terão duração de 1 semana, sempre iniciando e finalizando aos sábados.                                                                                                                          |
 | Sprint Planning          | As plannings ocorrerão sempre aos sábados no início da sprint através de reuniões síncronas. Para critérios de simplificação, a Sprint Planning será incorporada a Release Planning do XP.                                                                               |
 | Daily Scrum              | Serão feitas de forma assíncrona todos os dias pela equipe de desenvolvimento no decorrer da sprint.                                                                                                                         |
 | Sprint Retrospective     | As Retrospectives serão realizadas as quartas-feiras, por conta de disponibilidade da equipe.  |
@@ -121,7 +121,7 @@
 | User Stories (US) | As US serão a principal fonte de requisitos do projeto e auxiliaram para estimar os prazos para as entregas das funcionalidade do produto. |
 | Release Planning | A Release Planning servirá para definir o Backlog da Sprint de quais US serão implementadas. Devido ao espoco da disciplina de Requisitos as releases serão planejadas por prazos (by date). Além disso, a Sprint Planning do Scrum será englobada pela Release Planning por critérios de simplificação. |
 | Velocity Tracking | Tanto na Release Planning, como na Iteration Planning será utilizado o Velocity Tracking para auxiliar na definição dos prazos e nas estimativas de entrega das funcionalidades. |
-| *Planning Game⁴* | Método que transforma as plannings do XP em uma espécie de jogo, deixando as iterações e a rotina da metodologia mais dinâmica.  |
+| Planning Poker | Método para avaliação das histórias e consentimento acerca da US.  |
 | Sustainable, Measurable, Predictable Pace | O ritmo da equipe será avaliado durante todas as etapas de projeto, principalmente através do Velocity Tracking e das Retrospectives do Scrum. |
 | Stand up Meetings | Serão incorporadas as dailys do Scrum, com o propósito de responder as seguintes perguntas: O que foi feito ontem?; O que será tentado hoje?; e Quais problemas estão causando atrasos? |
 | Pair programming e Move people around | O Pair Programming servirá para melhoria na qualidade do produto, além de compartilhamento de experiência pela equipe. Para isso, o Move People Around também será muito útil, pois fará com que toda a equipe esteja capacitada em todas as áreas do produto. |
@@ -143,4 +143,3 @@
 1. Sommerville, Ian Engenharia de software/ Ian Sommerville; tradução Luiz Cláudio Queiroz; revisão técnica Fábio Levy Siqueira. 10. ed. São Paulo: Pearson Education do Brasil, 2018. Título original: Software engineering ISBN 978-65-5011-048-2 1. Engenharia de software I. Siqueira.
 2. The 2020 Scrum Guide TM. Scrum Guides, 2020. Disponível no [link](https://scrumguides.org/scrum-guide.html#purpose-of-the-scrum-guide). Acesso em: 27 de setembro de 2023.
 3. WELLS, Don. Extreme Programming: A gentle introduction. Extreme Programming, 2013. Disponível no [link](http://www.extremeprogramming.org/). Acesso em: 27 de setembro de 2023.
-4. Wiki C2. Planning Game, 2013. Disponível no [link](https://wiki.c2.com/?PlanningGame). Acesso em: 27 de setembro de 2023.
diff --git a/docs/doc-visao/4.processo-requisitos.md b/docs/doc-visao/4.processo-requisitos.md
@@ -78,8 +78,8 @@ Logo | Ferramenta | Finalidade |
 
 | Atividades | Métodos | Ferramentas | Entrega
 | --- | --- | --- | ---
-| Elicitação e descoberta | Entrevista com o cliente e Lean Inception | Microsoft Teams, Discord, Whatsapp, GitHub, Mural | Lista de personas, conjunto de requisitos funcionais e não funcionais
-| Análise e consenso | Lean Inception e Brainstorming | Microsoft Teams, Discord, Whatsapp, GitHub, Mural |  Lista de personas, conjunto de requisitos funcionais e não funcionais |
+| Elicitação e descoberta | Entrevista com o cliente e Lean Inception | Microsoft Teams, Discord, Whatsapp, Mural | Lista de personas, conjunto de requisitos brutos
+| Análise e consenso | Lean Inception e Brainstorming | Discord, e Mural |  Lista de personas, conjunto de requisitos funcionais e não funcionais |
 | Declaração | Estruturação segundo o SAFe | GitHub, Canva |  Backlog SAFe com histórias de usuário (US) e critérios de aceitação|
 | Organização e Atualização | MoSCoW e pontuação por entendimento técnico das histórias | GitHub, Canva | Histórias de usuário priorizadas segundo valor de negócio e entedimento técnico |
 | Verificação e Validação | Checklist e revisão informal de verificação e validação | GitHub, Canva, Discord, Whatsapp | Resultados dos checklist e feedbacks da revisão |
@@ -93,7 +93,7 @@ Logo | Ferramenta | Finalidade |
 | Atividades | Métodos | Ferramentas | Entrega
 | --- | --- | --- | ---
 | Representação | Prototipagem | Figma | Protótipo de baixa fidelidade das histórias da release
-| Declaração | Histórias de usuário e critérios de aceitação | Microsoft Teams e GitHub | US da sprint com critérios de aceitação |
+| Declaração | Histórias de usuário e critérios de aceitação | GitHub | US da sprint com critérios de aceitação |
 | Verificação e Atualização | INVEST e Definition of Ready | Microsoft Teams e GitHub | Checklist INVEST e DoR das US da sprint |
 | Organização e Atualização | Pontos por história | Microsoft Teams e GitHub | US da sprint pontuadas por esforço e valor para entrarem na sprint |
 
@@ -105,10 +105,10 @@ Logo | Ferramenta | Finalidade |
 
 | Atividades | Métodos | Ferramentas | Entrega
 | --- | --- | --- | ---
-| Elicitação e Descoberta | Descoberta de novos requisitos durante o desenvolvimento do produto | VSCode, Discord, Github e Whatsapp| Conjunto de requisitos funcionais e não funcionais brutos trazidos da sprint |
-| Análise e Consenso | Conversa com o cliente e análise dos requisitos levantados durante a sprint | Microsoft Teams, Discord e GitHub | Conjuntos de requisitos funcionais e não funcionais para entrar no backlog do projeto |
-| Declaração | Estruturação dos requisitos no backlog SAFe | Discord e GitHub | Histórias de usuário dos requisitos levantados durante a sprint |
-| Organização e atualização | Atualização do backlog do produto e do backlog da sprint (Planning Game) | Discord, Github e Whatsapp | Backlog da sprint atualizado e priorizado, bem como o backlog do produto |
+| Elicitação e Descoberta | Descoberta de novos requisitos durante o desenvolvimento do produto | VSCode, Github e Whatsapp| Conjunto de requisitos funcionais e não funcionais brutos trazidos da sprint |
+| Análise e Consenso | Conversa com o cliente e análise dos requisitos levantados durante a sprint | Microsoft Teams e GitHub | Conjuntos de requisitos funcionais e não funcionais para entrar no backlog do projeto |
+| Declaração | Estruturação dos requisitos no backlog SAFe | GitHub | Histórias de usuário dos requisitos levantados durante a sprint |
+| Organização e atualização | Atualização do backlog do produto e do backlog da sprint | Github | Backlog da sprint atualizado e priorizado, bem como o backlog do produto |
 
 <p style="display: flex; justify-content: center; font-size: 0.8em">Fonte: Autores, 2023</p>
 
@@ -118,8 +118,8 @@ Logo | Ferramenta | Finalidade |
 
 | Atividades | Métodos | Ferramentas | Entrega
 | --- | --- | --- | ---
-| Verificação e Validação | Definition of Done | Microsoft Teams, Discord, Whatsapp e GitHub | DoD das US entregues na sprint
-| Organização e atualização | Organização e atualização do Backlog do produto | Discord, Github e Whatsapp| Backlog priorizado e atualizado para a próxima sprint |
+| Verificação e Validação | Definition of Done | Microsoft Teams, Whatsapp e GitHub | DoD das US entregues na sprint
+| Organização e atualização | Organização e atualização do Backlog do produto | Microsoft Teams e Github | Backlog priorizado e atualizado para a próxima sprint |
 <p style="display: flex; justify-content: center; font-size: 0.8em">Fonte: Autores, 2023</p>
 
 

diff --git a/docs/doc-visao/5.licoes-aprendidas.md b/docs/doc-visao/5.licoes-aprendidas.md
@@ -29,6 +29,14 @@ Por conta das novas descobertas ao longo do projeto, muitos questionamentos e d
 
 ## Unidade 3
 
+Na Unidade 3 o grupo foi capaz de se aprofundar nos conceitos fundamentais do Product Backlog Building (PBB), Behavior Driven Developmente (BDD) e User Story Mapping (USM). Durante esse período de estudo, indentificamos a importância crucial dessas práticas no desenvolvimento de um software.
+
+Com o PBB, compreendemos a essencialidade de construir e manter um backlog de produto dinâmico e bem-priorizado. Isso não apenas nos permite adaptar os requisitos do produto, mas também facilita a identificação de prioridades para o desenvolvimento. O BDD nos proporcionou uma nova perspectiva na definição de comportamento do sistema. Por fim, o User Story Mapping (USM) nos mostrou como mapear e visualizar histórias de usuários, permitindo uma compreensão mais clara das necessidades requisitadas.
+
+Durante a Unidade 3, o grupo enfrentou desafios ao aplicar esses conceitos em cenários práticos, mas gradativamente conseguimos superá-los. Vale ressaltar a importância que a integração dessas práticas tem em aprimorar a comunicação e colaboração entre os membros da facção.
+
+Em suma, a Unidade 3 foi um marco significativo em nosso aprendizado, proporcionando insights valiosos sobre como utilizar o PBB, BDD e USM de maneira integrada para um processo de desenvolvimento de software mais eficaz e alinhado com as necessidades do cliente. Esses conceitos se revelaram ferramentas essenciais para garantir uma entrega mais eficiente, alinhada e centrada no usuário.
+
 ## Unidade 4
 
 ## Referências Bibliográficas

diff --git a/docs/dor_dod.md b/docs/dor_dod.md
@@ -6,7 +6,34 @@
 
 Definition of Ready (DoR) e Definition of Done (DoD) são critérios fundamentais no contexto ágil do desenvolvimento de software. DoR define as condições que um item do backlog deve atender antes de ser selecionado para o sprint, garantindo que esteja claro, compreensível e pronto para ser desenvolvido. Isso pode incluir a existência de detalhes suficientes, critérios de aceitação bem definidos e uma compreensão compartilhada entre a equipe. Por outro lado, o DoD estabelece os critérios que um incremento de trabalho deve cumprir para ser considerado completo, testado, pronto para produção e entregável. Esses critérios garantem que o trabalho atenda aos padrões de qualidade, funcione conforme o esperado e esteja em conformidade com os requisitos antes de ser considerado finalizado. Juntos, o DoR e o DoD asseguram uma melhor compreensão, consistência e qualidade ao longo do ciclo de desenvolvimento ágil.
 
-Abaixo, está apresentado o [DoR e o DoD](./assets/dor_e_dod.png) proposto para a resolução do problema:
+## DoR - Definition of Ready
 
-![USM](./assets/dor_e_dod.png)
+Os seguintes critérios foram definidos para o DoR desse projeto:
 
+* **O requisito está declarado como uma história de usuário?**
+
+* **A história tem critérios de aceitação definidos?**
+
+* **A história tem valor de negócio estabelecido?**
+
+* **A história está de acordo com o modelo do INVEST?**
+
+* **A história foi estimada em pontos, levando em conta os critérios de aceitação?**
+
+* **A história tem representação no formato de um protótipo?**
+
+* **A história foi validada pelo cliente?**
+
+## DoD - Definition of Done
+
+Os seguintes critérios foram definidos para o DoD desse projeto:
+
+* **Os critérios de aceitação foram desenvolvidos e verificados?**
+
+* **O código desenvolvido está de acordo com a arquitetura do projeto?**
+
+* **O código desenvolvido é responsivo com os modelos de tela estabelecidos para o projeto?**
+
+* **A funcionalidade desenvolvida foi revisada por um membro da equipe?**
+
+* **A funcionalidade está integrada ao sistema principal da aplicação?**
diff --git a/docs/entregas/dor_dod.md b/docs/entregas/dor_dod.md
diff --git a/docs/entregas/3.entrega-unidade3.md → ...entregas/unidade-03/1.entrega-unidade3.md b/docs/entregas/3.entrega-unidade3.md → ...entregas/unidade-03/1.entrega-unidade3.md
diff --git a/docs/entregas/unidade-03/2.pbb.md b/docs/entregas/unidade-03/2.pbb.md
@@ -0,0 +1,20 @@
+# PBB
+
+## Histórico de Revisão
+
+| **Data**  | **Versão** | **Descrição**        | **Autor**                                                     |
+| --------- | ---------- | -------------------- | ------------------------------------------------------------- |
+| 22/11/2023 | 0.1        | Criação do documento | [João Barreto](https://github.com/JoaoBarreto03) |
+
+
+O Product Backlog Building (PBB) é uma abordagem empregada no âmbito da gestão ágil de projetos de software. Trata-se de uma estratégia para a constante elaboração e aprimoramento do Backlog do Produto, uma lista dinâmica e priorizada que engloba todos os requisitos, funcionalidades, aprimoramentos e correções essenciais para um produto. O PBB implica na criação e atualização iterativa do backlog, incorporando novos elementos à medida que são identificados, eliminando ou aperfeiçoando aqueles que se tornam mais claros ou menos relevantes com o tempo, e priorizando-os com base no valor de negócio que proporcionam ao produto. Essa abordagem tem como objetivo manter o backlog constantemente alinhado com as demandas do produto e do cliente, viabilizando uma adaptação e evolução mais eficazes ao longo do ciclo de desenvolvimento.
+
+## O que é a HealthNet?
+
+A HealthNet é uma rede de clínicas e hospitais que está passando por dificuldades no gerenciamento de seus dados. Os problemas e necessidades da HealthNet podem ser vistos de forma mais detalhada por meio deste [link](https://aprender3.unb.br/pluginfile.php/2665941/mod_folder/content/0/Exerc%C3%ADcio%20de%20Constru%C3%A7%C3%A3o%20de%20Backlog%20de%20Produto%20usando%20PBB.pdf)
+
+## PBB - Guardiões da Galáxia
+
+Com base no documento apresentado no tópico acima, foi elaborado um PBB que atendesse as necessidades da HealthNet. Abaixo segue o quadro no Miro com esse PBB:
+
+<iframe width="800" height="400" src="https://miro.com/app/board/uXjVNR4a-Y4=/?share_link_id=638785315337" frameborder="0" allowfullscreen></iframe>
diff --git a/docs/entregas/pbb.md → docs/entregas/unidade-03/3.pbb-revisao.md b/docs/entregas/pbb.md → docs/entregas/unidade-03/3.pbb-revisao.md