Fechamento da sprint 01

1. Resumo da Sprint

Pontos concluídos: 31 pontos

• Histórias entregues:

• TS06 - Elaboração do Documento de Visão

• S07 - Estudar Python/Django (Focado em Classy Class-Based Views.)

• TS09 - Elaborar Docker para ambiente de Desenvolvimento.

• TS11 - Criar Documentação do Git.

• TS12 - Elaborar Templates de Issues e Pull Requests.

• TS13 - Elaborar Termo de Abertura do Projeto.

• S10 - Criar estrutura inicial do projeto Django.

Assim como na Sprint 0, todas as histórias foram entregues. Entretanto, possivelmente o Documento de Visão terá que ser revisto em virtude das informações que temos do projeto no presente possivelmente mudarem no futuro, o que afetará essa documentação.

2. Retrospectiva

Pontos Positivos	Pontos Negativos	Sugestão de Melhoria
Aprender sobre a documentação (Documento de Visão)	Indefinição do escopo	Melhorar a produtividade ao vivo entre os MDS
Integração do grupo MDS	Trabalho extra desnecessário	Deixar mais claro como estão as atividades de MDS
Aprendizagem com os erros	Impossibilidade de trazer o notebook pra FGA	-
Conhecimento de novas ferramentas	-	-
Arrumamos um local de reunião melhor	-	-
MDS procurando auxílio quando necessário	-	-
Melhor integração de EPS	-	-

3. Quadro de Conhecimento

Com a melhor definição das tecnologias que serão utilizadas na execução do projeto, foram feitas alterações nos ítens do Quadro. A coluna Java foi removida, pois esta linguagem não será utilizada. No lugar dele, entrou o Docker, que é uma ferramenta que será utilizada amplamente no projeto, indo desde o ambiente local que o Time de Desenvolvimento usará quando estiverem codando a aplicação até o ambiente de produção.

Comparando o Quadro dessa Sprint com o da anterior, nota-se 2 coisas preocupantes: o Docker só é conhecido bem por dois membros da equipe. A segunda é que não houve mudanças no Quadro de Conhecimento nas tecnologias que também estiveram presentes na Sprint 0. Isso demonstra que os dojôs não foram bem sucedidos no seu objetivo de tornar familiarizar os membros do Time de Desenvolvimento com o git.

4. Burndown Chart

Assim como na Sprint 0, o Burndown Chart teve formato de "desfiladeiro", com todas as entregas ocorrendo no último dia da sprint. Isto é algo a ser observado e mudado para as próximas sprints, pois representa um risco para o projeto.

5. Velocity

Assim como na Sprint 0, nesta todos os pontos planejados foram entregues, mesmo a quantidade deles tendo aumentado. Como consequência disso, a velocity da equipe subiu, o que é algo positivo.

6. Risk Burndown

Conforme a figura acima mostra, no primeiro Risk Burndown o maior risco atual para o projeto é a incerteza com relação ao escopo e às informações sobre o projeto que será feito. A única certeza que temos até o fim dessa sprint é a do o contexto no qual será inserida a aplicação desenvolvida pela equipe. Para mitigar esse risco, tanto a Product Owner quanto o Scrum Master buscarão obter informações mais acertadas sobre o Dr. Down.

O risco de o Time de Desenvolvimento também foi alto, e isto se deve ao que foi demonstrado pelo Quadro de Conhecimento e também por eles ainda não terem começado a programar, para que assim demonstrem qual o nívem real de adaptação deles às tecnologias utilizadas.

7. Gráfico de Commits

Conforme o gráfico acima mostra, os commits durante a Sprint 1 fnão ficaram restritos a apenas alguns dias da semana, enquanto outros não tiveram atividade. Isto é positivo, pois demonstra que a equipe esteve sempre trabalhando, o que diminui os riscos relacionados deixarem pra fazer tudo de uma vez, especialmente se for próximo ao fim da sprint.

8. Análise do Scrum Master

A Sprint 1 foi muito atrapalhada pela falta de informações mais certas sobre o projeto, pois só pudemos colocar o Time de Desenvolvimento para criar o Documento de Visão, quando a ideia inicial era também colocar eles para fazerem o de Arquitetura e de Especificação Suplementar. Isso já trouxe um atraso para o que estava planejado para as primeiras sprints, e deverá ser resolvido o quanto antes.