Sprint 5
Planejamento
1. Objetivos e Duração
Duração:
17/09/2018 a 25/09/2018
2. Sprint Backlog
3. Pontuação da Sprint
4. Papéis
5. Pareamento
6. Riscos da Sprint
Os riscos indentificados nesta sprint foram:
Resultado
1. Sprint Review
A maioria das tarefas separadas para esta sprint foram realizadas com sucesso.
A única tarefa que não foi terminada foi "Criar Mapa de Requisitos".
Tal tarefa não foi aceita como entregue pois faltaram detalhes referentes aos
requisitos de Gamificação do projeto.
Foram efetuados 16 pontos referentes à pontuação desta sprint e 2 pontos de
dívida técnica da sprint passada (história de refatoração do protótipo de alta
fidelidade).
As histórias não entregues foram:
Refatorar Modelo do Banco de Dados ,
Configurar Ambiente de Homologação e Produção e
Construir back-end de profile . O MER do banco de dados não foi
totalmente refatorado e por isso ficou como dívida. Já a configuração do
ambiente de homologação e produção não foram realizados pois o deploy não
estava funcionando totalmente. Por fim, devido a trocas de tecnologia
durante à execução da sprint por causa de decisões entre os grupos do
aplicativo geral da FGA o back-end de profile teve que ser alterado e não
houve tempo hábil para tal solução. Tal acontecimento gerou um risco não
mapeado no meio da sprint sendo ele decisões externas ao nosso serviço
.
2. Sprint Retrospective
| Pontos Positivo | Pontos Negativos | Soluções |
|---|---|---|
| Empenho da equipe | Várias tecnologias novas | Pesquisar mais sobre as tecnologias a serem utilizadas |
| Produtividade | Gasto de muitas horas nas atividades (má pontuação de histórias) | Otimizar estudo externo às atividades |
| Proatividade | Muito estudo de outras matérias | Repensar pontuação das histórias que envolvam código |
| União da Equipe | Trocas de tecnologias | Modularizar ao máximo o nosso serviço para não depender dos serviços dos outros grupos |
| Aprendizado da Equipe | Muito sono | - |
| Implentação do projeto | Outros grupos para integrar | - |
| Notificações funcionando | Provas na próxima semana | - |
| Boa comunicação entre a equipe | - | - |
3. Quadro de Conhecimento
4. Burndown
Obs: Pode-se reparar que a equipe passou a utilizar o zenhub de uma maneira mais correta do que na sprint passada. Além disso pode-se observar também que as issues desta sprint foram realmente entregues no dia do deadline.
5. Velocity
O velocity se manteve em 17 pontos.
6. Gráfico de Commit
7. Burndown de Riscos
Este burndown de riscos possui uma escala de 0 a 30 de um risco acontecer.
Sendo 0 risco nulo e 30 risco altíssimo.
Obs: Por ser a primeira sprint onde o burndow de risco foi implementado
o burndown se tornou constante.
8. Análise do Scrum Master
Dentre as sprints que já ocorreram esta foi de longe a mais
turbulenta. Grande parte das histórias foi entregue entretanto houveram grandes
problemas relacionados às tecnologias utilizadas para a trasmição de
notificações entre dispositivos. Tal troca de tecnologia fez com que o
projeto literalmente parasse por volta de dois dias. A solução foi encontrada
pela DevOps da equipe (Taynara Carvalho) que trabalhou arduamente
com a equipe de desenvolvimento para sanar tal problema.
Sobre a história referente ao perfil de usuário nós trabalhamos com
um plano B para caso a equipe geral do APP não entregasse o login tivéssemos
um social login para podermos testar nossa aplicação. Acabou que a
equipe geral do APP mudou a ideia do social login e fizeram um login direto na
API
fornecida por eles o que acabou que tornou a nossa história (do plano B) em uma
história que basicamente aceitava o login deles e gerava um profile de usuário
na
nossa aplicação. Tal história não ficou pronta até o fim da sprint (gerando um
novo risco referente à problemas externos a nossa equipe).
Os riscos da sprint que ocorreram foi o referente a configuração do
rancher 2.0 não ocorrer perfeitamente o que, de certa forma, afetou o trabalho
tanto do DevOps quanto
do Arquieto, logo, para a próxima sprint a equipe deve focar nestas histórias e
o scrum master deve procurar soluções e auxílio para as próprias. Além deste
risco ficou muito óbvio
que as histórias de usuário que possuiam código propriamente dito foram muito
mal pontuadas pois cada uma delas (somando por módulo criar e enviar) somaram
mais ou menos 2~3 pontos
o que deveria resultar em aproximadamente 6 horas de trabalho e na realidade
necessitaram de mais de dez horas. Logo, para a proxima sprint é extremamente
necessário que se repense em
como pontuar as histórias que necessitem de código.
Por fim vale ressaltar que a utilização do burndown gerado pelo
zenhub começou a ser feita corretamente o que demonstrou que a equipe, nesta
sprint, realmente
fez entregas literalmente no dia do deadline. Logo o scrum master deve procurar
uma maneira de corrigir tal atitude mesmo acreditando que muito disso ocorreu
pela
equipe ter literalmente parado por causa da procura por uma nova tecnologia
para a transmissão de notificações.