docs/sprints/Fechamento-Sprint-3.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-conhecimentos)
>[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 | [Viabilidade Técnica ELK Stack](https://github.com/fga-eps-mds/2018.2-Lino/issues/75) | Aberta | 2 |
| ISSUE | [Evoluir a Arquitetura do Projeto](https://github.com/fga-eps-mds/2018.2-Lino/issues/73) | Aberta | 5 |
| ISSUE | [US07 - Comunicar o Lino com o mensageiro Messenger](https://github.com/fga-eps-mds/2018.2-Lino/issues/71) | Aberta | 3 |
| ISSUE | [US06 - Transformar cardápio (PDF) em texto](https://github.com/fga-eps-mds/2018.2-Lino/issues/70) | Fechada| 5 |
| ISSUE | [Estudar a tecnologia RabbitMQ](https://github.com/fga-eps-mds/2018.2-Lino/issues/69) | Fechada| 2 |
| ISSUE | [Criar DockerFile para desenvolvimento](https://github.com/fga-eps-mds/2018.2-Lino/issues/53)|Fechada| 3 |
### 2.3 Pontuação Final
* __Pontuação Total:__ 20 Pontos Planejados
* __Débitos Técnicos Adicionados:__ 21 Pontos
* __Pontos Concluídos:__ 20 Pontos Concluídos
* __Pontos Não Agregados:__ 21 Pontos Não Agregados Nessa Sprint
### Débitos Técnicos da Sprint Anterior
* US05 - Buscar informações sobre o Cardápio do RU: 3 pontos (Aberto)
* US22 - Definição da Identidade visual do Lino: 8 pontos (Aberto)
* Elaborar o Backlog de Produto: 5 pontos (Fechado)
* Criar Dockerfile para Desenvolvimento: 5 pontos (Fechado)
### Débitos Técnicos Gerados
* Viabilidade Técnica ELK Stack
* Evoluir a Arquitetura do Projeto
* US07 - Comunicar o Lino com o mensageiro Messenger
Todos esses documentos se tornaram débito técnico, pois ocorreram atrasos devido à configuração de ambiente de alguns membros, além de mudanças pontuais na definição da arquitetura e identidade visual.
------------
## 3. _Burndown Chart_
------------
## 4. Velocity
------------
## 5. Retrospectiva da _Sprint_
| Pontos Positivos | Pontos Negativos | Pontos a Melhorar |
| :---------------------------------------: | :---------------------------------: | :----------------------------------------------------: |
| Aprendizado API Facebook | Identidade visual | Melhorar o Docker |
| Conhecimento Python | Sprint começando tarde | Reporte de acontecimentos nas issues |
| Conhecimento de WebCrawler | Docker instável | Mais proatividade, tomar decisões descentralizadamente |
| Organização das tarefas em forma de issue | Comunicação falha | Organização pessoal |
| Estudo da Docker | Provas | Organização do grupo em si |
| Aprendizado RabbitMQ | Teste com RabbitMQ e ELK não saíram | Aplicação da metodologia (rituais, gitflow etc) |
| Aprendizado ELK | Falta de pontualidade | Fazer daily na quarta |
| Evolução da Arquitetura | Dificuldade de Pareamento |
------------
## 6. Quadro de Conhecimento
------------
## 7. Quadro de Presença Daily
------------
## 8. Riscos Mapeados
Nessa sprint, os riscos principais foram a mudança de arquitetura e integração entre os serviços. Um ponto principal também foi a dívida técnica e falta de planejamento por parte de EPS.
Em relação aos atrasos de entrega, isso em boa parte deu por conta da prática de DevOps ainda estar amadurecendo dentro da equipe; foi um risco planejado mas não mitigado e acabou se concretizando: vários membros do time tiveram problemas com o ambiente e não conseguiram entregar o planejado.
------------
## 9. Visão do Tech Lead
<p align="justify"> A necessidade desta <i>Sprint</i> consolidar o desenvolvimento, dando início ao fechamento das primeiras funcionalidades logo após a disponibilização do Docker, para configuração de ambiente dos desenvolvedores. Também, foi dado início aos estudos das ferramentas de BI e orquestração dos microsserviços, utilizando o Stack ELK e RabbitMQ, respectivamente.</p>
<p align="justify"> Porém, algumas issues relacionadas a desenvolvimento acabaram como débito técnico, por conta do DevOps e do ambiente não padronizados. Além disso, a identidade visual passou para a <i>Sprint</i>, porém obteve significativo desenvolvimento e se encaminha para a conclusão. Obteve-se boa evolução na consolidação da arquitetura do projeto, permitindo a equipe de desenvolvimento ter conforto nas suas tarefas relacionadas à isso.</p>
------------