Sprint 6
Planejamento
1. Objetivos e Duração
Duração:
25/09/2018 a 01/10/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
Após a sufocante sprint passada a equipe conseguiu com sucesso realizar todas
as issues designadas para esta sprint. Pelo burndow pode-se perceber que grande
parte das histórias
foi entregue no dia do deadline entretanto vale ressaltar que houve uma força
tarefa da quipe inteira (MDS+EPS) na construção do core do produto. No caso
Profile e Notification.
2. Sprint Retrospective
| Pontos Positivo | Pontos Negativos | Soluções |
|---|---|---|
| Equipe proativa | Entregas muito próximas do deadline da sprint | Pesquisar mais sobre as tecnologias a serem utilizadas |
| O deploy saiu! | Mal uso do zenhub | Otimizar estudo externo às atividades |
| O código deu certo! | Construção do serviço dentro de um app com mais serviços externos | Repensar pontuação das histórias que envolvam código |
| Todas as histórias foram entregues | Final de semana rushado | Modularizar ao máximo o nosso serviço para não depender dos serviços dos outros grupos |
| Momento de distração em reunião presencial | Galera se irritando com os companheiros de equipe | - |
3. Quadro de Conhecimento
Nesta sprint foram adicionadas novas tecnologias no quadro de conhecimento específico de DevOps e de Arquiteto.
4. Burndown
Obs: O burndown iniciou-se com uma queima razoávelmente boa de pontos entretanto algum tempo depois as histórias voltaram a ser entregues no deadline da sprint.
5. Velocity
O velocity se alcançou em 18 pontos até a release 1.
6. Gráfico de Commit
Microserviço: Notification
Microserviço: Profile
7. Burndown de Riscos
Houve uma queda nos riscos que vieram da sprint passada. Isso
provavelmente aconteceu pois houve um aumento significativo da
experiência do time
em relação às tecnologias utilizadas.
Foram adicionados os riscos
encontrados nesta sprint no burndown.
8. Análise do Scrum Master
Como dito anteriormente, após a sprint mais turbulenta que ocorreu
neste projeto houve uma sprint onde todas as histórias planejadas foram
alcançadas. Como
ponto negativo para a sprint em geral há o fato de que não foi possível gerar o
APK até a apresentação da release 1 o que nos leva a utilizar o "plano B" que é
apresentar o core do produto utilizando o simulador do EXPO. O adiamento da
criação do apk foi devido a demora da conclusão do deploy dos backends. E este
segundo atraso
ocorreu pois houveram muitos problemas com a utilização do rancher 2.0 (na
orquestração dos containers) o que nos fez optar pela utilização do rancher
1.6. Vale ressaltar
também que o APK gerado para a nossa apresentação deveria conter também os
demais projetos do APP geral da FGA o que não pode ocorrer muito provavelmente
por não haver uma
sincronia entre o fim das sprints de cada um dos projetos.
Um grande ponto a se observar também é que no decorrer desta sprint
o pareamento se tornou um bloqueio para a execução de algumas das tarefas pois
elas eram muito
dependentes umas das outras logo, para tal, foi instruído a equipe que, visando
a entrega das funcionalidades na data correra, fossem realizadas reuniões
gerais para a codificação.
Tal medida se mostrou bem sucedida já que tudo foi entregue. Entretanto não é
uma boa prática a ser utilizada recorrentemente pois nem sempre é possível
encontrar um horário onde toda
a equipe possa se encontrar.
Já sobre os riscos desta sprint realmente caímos em um deles que
foi a não geração do apk o que ativou nosso plano B que é organizar uma
apresentação utilizando o
simulador do EXPO já que nosso core de produto está completamente pronto.
Em paralelo à toda sprint ocorreu uma revisão do documento de
arquitetura e do documento de visão do projeto como também de algumas páginas
do github pages. Tal alteração
ocorreu visando uma melhor apresentação da release 1. Tal história não
necessitou ser definida ou pontuada pois haviam apenas algumas alterações a
serem feitas como por exemplo a falta de
algumas referências e falta de alguns links.
Concluindo pode-se perceber que houve um bom desempenho da equipe
na release 1 o que cuminou no fato de que a própria iniciará o processo para a
release 2 sem pontos de dívidas técnicas. O quadro de conhecimentos mostra que
o conhecimento das ferramentas pela parte da equipe de MDS cresceu como também
o conhecimento das ferramentas de DevOps e Arquitetura pela parte do DevOps e
do Arquiteto do projeto o que mostra que a equipe continua em desenvolvimento
buscando encontrar um ponto de fluidez.