docs/sprints/Fechamento-Sprint-4.md
# Sumário
>[1. Relato da Sprint](#1-relato-da-sprint)
>[2. Fechamento da Sprint](#2-fechamento-da-sprint)
>[3. Burndown Chart](#3-brundown-chart)
>[4. Velocity](#4-velocity)
>[5. Retrospectiva da Sprint](#5-retrospectiva-da-sprint)
>[6. Quadro de Conhecimento](#6-quadro-de-conhecimento)
>[7. Quadro de Presença Daily](#7-quadro-de-presença-daily)
>[8. Riscos Mapeados](#8-riscos-mapeados)
>[9. Visão do Tech Lead](#9-visão-do-tech-lead)
## 1. Relato da _Sprint_
<p align="justify"> Nesta <i>Sprint</i>, os objetivos foram levantar e fechar o escopo do projeto, assim como documentar, a nível de produto, o que o projeto propõem.
------------
## 2. Fechamento da _Sprint_
### 2.1 Backlog da Sprint
| ID | História | Status | Pontos |
|:--:| ------- | :----: | :----: |
|ISSUE|[US01 - Notificação sobre o cardápio diário do RU](https://github.com/fga-eps-mds/2018.2-Lino/issues/87)|Aberto|5|
|ISSUE|[Aplicar Arquitetura do projeto e Aperfeiçoar DevOps para arquitetura](https://github.com/fga-eps-mds/2018.2-Lino/issues/73)|Aberto|5|
|ISSUE|[US11 - Conexao Lino-Gmail](https://github.com/fga-eps-mds/2018.2-Lino/issues/83)|Aberto|5|
|ISSUE|[US12 - Armazenar o conteúdo das conversas em um banco de dados](https://github.com/fga-eps-mds/2018.2-Lino/issues/77)|Fechado|5|
|ISSUE|[Modelar o NFR](https://github.com/fga-eps-mds/2018.2-Lino/issues/85)|Fechado| - |
### 2.3 Pontuação Final
* __Pontuação Total:__ 20 Pontos Planejados
* __Débitos Técnicos Adicionados:__ 21 Pontos
* __Pontos Concluídos:__ 26 Pontos Concluídos
* __Pontos Não Agregados:__ 15 Pontos Não Agregados Nessa Sprint
### Débitos Técnicos da Sprint Anterior
* US05 - Task 1 - Criar JSONs para retornar o cardápio semanal, e de cada refeição: Não pontuado (Aberto)
* US22 - Definição da Identidade visual do Lino: 8 pontos (Fechado)
* Viabilidade Técnica ELK Stack: 2 pontos (Fechado)
* Evoluir a Arquitetura do Projeto: 5 pontos (Fechado)
* US07 - Comunicar o Lino com o mensageiro Messenger: 3 pontos (Fechado)
* US05 - Task 2 - Buscar informações sobre o Cardápio do RU: 3 pontos (Fechado)
### Débitos Técnicos Gerados
* Aplicar Arquitetura do projeto e Aperfeiçoar DevOps para arquitetura
* US01 - Notificação sobre o cardápio diário do RU
* US11 - Conexao Lino-Gmail
Todos esses documentos se tornaram débito técnico, pois ocorreram atrasos devido à muitos membros terem provas e priorização de outras matérias.
------------
## 3. _Burndown Chart_
------------
## 4. Velocity
------------
## 5. Retrospectiva da _Sprint_
| Pontos Positivos | Pontos Negativos | Pontos a Melhorar |
| :---------------------------------------------------------: | :------------------------: | :--------------------------------: |
| Pareamento entre duplas | Organização do Tech Leader | Constância do Fechamento de Issues |
| Conhecimento de Python, Node, Rasa, API do Gmail e Facebook | Falta da dupla | Diminuir Pontos Negativos |
| Conhecimento de Docker e Webcrawler | Curva de Aprendizado Alta | |
| Feedback da Carla | Tristeza Pós Provas | |
| Empenho da Equipe | Testar o Banco | |
| Conhecimento de EPS com relação os serviços | | |
------------
## 6. Quadro de Conhecimento
------------
## 7. Quadro de Presença Daily
------------
## 8. Riscos Mapeados
Nessa sprint, os risco principais, ainda se encontravam na dívida técnica e qualidade de interação do bot: devido aos atrasos e entrega inacabada, a qualidade do produto ficou prejudicada e pouco valor acabou sendo entregue.
O ponto positivo fica para a mitigação do risco de arquitetura, uma vez que esta foi consolidada e o risco acabou caindo em relação às sprints anteriores.
------------
## 9. Visão do Tech Lead
<p align="justify"> A necessidade desta <i>Sprint</i> continuar o ritmo de desenvolvimento, aumentando fechamento das funcionalidades logo após a estabilização do ambiente da equipe. Também, foi realizado a organização dos microsserviços, baseando-se a arquitetura de repositórios e auxílio da ferramenta RabbitMQ.</p>
<p align="justify"> Porém, algumas issues relacionadas a desenvolvimento acabaram como débito técnico, por motivos de provas e tentativa de conciliar as duas matérias, mas as provas acabaram sendo priorizadas. Obteve-se consolidação da arquitetura do projeto, permitindo a equipe de desenvolvimento ter conforto nas suas tarefas relacionadas à isso e integração de desenvolvimento de EPS/MDS.</p>
------------