Sprint 11
Planejamento
1. Objetivos e Duração
Duração:
30/10/2018 a 05/11/2018
2. Sprint Backlog
3. Pontuação da Sprint
3.1. Sistema de pontuação Release 2
| Tipo de Tarefa | Extensão | Pontos Equivalentes |
|---|---|---|
| Pequenas alterações de código/front - estilização CSS | PP | 1 |
| CRUD, bugfix em CRUD, documentação pequena, relatório de sprint | P | 2 |
| Refatoração de código, nova função de back, nova função de front, documentação extensa | M | 3 |
| Nova feature (back/front), alteração de arquitetura, alteração de DevOps | G | 5 |
| Bugfix complexo, geração de relatório complexo | GG | 8 |
4. Papéis
Obs: O papel de scrum master voltou ao scrum master anterior pois como houve uma grande mudança no projeto a equipe tomou a decisão de alocar um scrum master que obteve mais experiência com este projeto.
5. Pareamento
6. Riscos da Sprint
Os riscos indentificados nesta sprint foram:
Resultado
1. Sprint Review
A maioria das issues da sprint foram fechadas. A issue referente a aplicação de uma ferramenta que coletasse as métricas de código do projeto não foi entregue. Tal
fato ocorreu pois o responsável por tal issue não conseguiu fazer a aplicação corretamente deixando-a para a próxima sprint como dívida técnica. Sobre as demais issues
foram corretamente entregues.
2. Sprint Retrospective
| Pontos Positivo | Pontos Negativos | Soluções |
|---|---|---|
| Issues referentes a código foram todas entregues | Provas de outras disciplinas | Configurar o APK para usar o login do Facebook |
| O APK foi enfim gerado | Mineiração de bitcoins indevida em nosso servidor rancher (pessoas externas à equipe estavam minerando estes bitcoins) | Acabar com a mineração de bitcoins em nosso servidor (pessoas externas à equipe estavam minerando estes bitcoins) |
| Nova interface de profile muito linda | - | - |
| Proatividade do time mesmo com as adiversidades | - | - |
| Time apresentou uma evolução sem precedentes | - | - |
| Saída do CarDefense do Integra | - | - |
3. Quadro de Conhecimento
O quadro de conhecimento vem mantendo um certo comportamento. Talvez a equipe tenha chegado a um ponto onde consegue manter um ritmo de trabalho sem necessitar de novos aprendizados mais complexos. Entretanto é necessário que ainda haja uma certa atenção ao conhecimento sobre testes de aceitação ou testes de front.
4. Burndown
O burndown voltou a apresentar as entregas constantes durante a sprint. A equipe está utilizando, de certa maneira, muito bem o zenhub fechando as issues assim que há a entrega. O problema que voltou a surgir neste burndown foi a entrega da dívida técnica antes da coleta do burndown. O Scrum Master da equipe deve, sempre, colher os dados assim que a equipe entregar a sprint.
5. Velocity
O velocity da equipe continua a confirmar que a pontuação de sprint em que o time se sente confortável é por volta de 25 pontos. Assim sendo é importante que o planejamento das próximas sprints mantenha a pontuação em torno deste valor.
6. Gráfico de Commit
Microserviço: Notification
Microserviço: Profile
Microserviço: Cars
Front-End
Como alguns repositórios não sofreram alterações nesta sprint alguns gráficos se manteram iguais aos da sprint passada. Uma boa decisão para as próximas sprints seria trazer ao relatório somente as mudanças ocorridas na própria sprint. Deixando o relatório mais enxuto.
7. Burndown de Riscos
Para melhor visualização CLIQUE AQUI
Pontuação: A escala do score de riscos vai de 0 (risco nulo) a 30 (risco extremamente alto)
É possível observar neste burndown de riscos que os riscos encontrados até esta sprint foram muito bem mitigados chegando a zero
é importante que os próximos scrum masters continuem a tomar boas decisões, sempre em cima das métricas coletadas, visando atacar os riscos encontrados
em cada uma das sprints.
8. Análise do Scrum Master
A equipe continua com um ótimo ritmo sempre entregando a totalidade ou a maioria das issues. Como dito no relatório a única issue que não foi entregue foi a referente à
coleta das métricas de código. Logo é importante que o scrum master continue a motivar a equipe e procure manter o planejamento da sprint, junto ao product owner, sempre
com um valor de pontuação confortável para a equipe.
A separação do App Integra nos permitiu mitigar o risco referente a criação do APK. Agora nosso app possui um sistema de login próprio o que nos permite testar todas as funcionalidades
do projeto implementadas até o momento como também já podemos fazer nosso deploy na produção (na google store). A equipe agora deve manter o foco visando a entrega total do app para a próxima release
que se aproxima.
Vale ressaltar, também, que para a próxima sprint o papel de scrum master pode voltar a rodar pela equipe de MDS. Para que tal objetivo seja alcançado é importante que
o scrum master atual auxilie o membro da equipe de MDS visando manter a motivação e o ritmo da equipe.
Logo é possível verificar um bom andamento do projeto. É importante que toda a equipe esteja sempre alerta para o surgimento de novos riscos e problemas visando que
o tempo de projeto está se esgotando como também as provas de fim de semestre estão mais próximas.