1. Objetivos e Duração

Ajustar front end da aplicação

Adição de imagem às notificações (públicas e privadas)

Iniciar microsserviço de carros

Duração:
09/10/2018 a 15/10/2018

2. Sprint Backlog

3. Pontuação da Sprint

Planejados: 21 pontos

Executados: 16 pontos

Dívida Técnica da sprint anterior: 0 pontos

3.1. Sistema de pontuação Release 2

4. Papéis

Engenheiro de Produto: Stéfane Souza

Scrum Master: Lucas S. Souza

DevOps: Taynara Carvalho

Arquiteto: Mateus Vieira

Desenvolvedores: João Gabriel Rossi, João Gabriel Antunes, Paulo Vitor, Ivan Diniz, João Matheus, Lieverton Santos

5. Pareamento

João Matheus e João Gabriel Antunes

Ivan e Lieverton

Paulo Rocha e Gabriel Rossi

6. Riscos da Sprint

Os riscos indentificados nesta sprint foram:

Membros desinteressados e desaparecidos

Mal uso do gitflow

Técnica nova para equipe: adicionar imagens às notificações

1. Sprint Review

A maioria das tarefas da sprint foram entregues entretanto a de imagens nas notificações privadas não ocorreu. Tal problema aconteceu pois houveram problemas relacionados ao momento de anexar a imagem a uma notificação. Já que os responsáveis pelas imagens nas notificações públicas obtiveram sucesso é necessário que, mesmo sendo uma dívida técnica, procurem auxiliar a equipe das notificações privadas.

2. Sprint Retrospective

3. Quadro de Conhecimento

O quadro de conhecimentos continua bem semelhante ao anterior. Ainda pode-se perceber uma certa defasagem no conhecimento da equipe tanto em metodologia, teste unitários e testes de aceitação. É importante que tal defasagem seja considerada na realização das sprints posteriores antes que tal ponto se torne um gargalo.

4. Burndown

Pode-se observar uma frequencia maior de entregas durante a sprint e já uma boa utilização do zenhub nesta sprint. Não pode ser vista nesse burndown a dívida técnica desta sprint (5 pontos). Tal fato ocorreu pois o burndow foi colhido após a dívida técnica ser entregue. Logo é importante dar enfâse: 5 pontos desta sprint não foram entregues durante sua execução!

5. Velocity

Pode-se perceber claramente uma grande redução tanto dos pontos planejados quanto do velocity em si. Isso ocorreu devido a decisão de procurar uma quantidade ideal e saúdavel de pontos por sprint. Além disso o velocity foi drásticamente afetado devido, também, à issue não entregue desta sprint.

6. Gráfico de Commit

Microserviço: Notification

Microserviço: Profile

Microserviço: Cars

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)
Houve a adição de novos riscos nesta sprint. Os riscos antigos foram parcialmente mitigados.
Obs: O diagrama de burndown de riscos foi refatorado vizando uma melhor visualização do próprio.

8. Análise do Scrum Master

  A sprint foi parcialmente entregue. O risco da adição das imagens às notificações não foi devidamente mitigado. Realmente se tornou um gargalo o que acarretou na não entrega de uma issue de 5 pontos. É importante que para as próximas sprints procure-se identificar estes problemas antes de designar uma tarefa tão "grande" assim.

  Visando a mitigação do risco de membros desaparecendo e se desinteressando foi feita uma reunião de alinhamento da equipe onde cada membro explicou sua situação e suas dores. Tal reunião foi Sbem produtiva. Se tornou conhecimento da equipe, inclusive, que um dos membros sofre de crises de ansiedade e não havia informado à toda equipe ainda. Logo, se torna ainda mais importante encontrar um valor ideal e saúdavel de entregas por sprint.

  No gráfico de commits é possível perceber que alguns membros estão destoando no trabalho entre front e back no sentido que contribuem mais em um do que no outro. Talvez isto ocorra pela aptidão dos membros. Assim sendo talvez seja bom que nas proximas duplas de pareamento ocorra pareamento entre membros que produzem mais no front juntamente com membros que produzem mais no back visando um nivelamento de conhecimento.

  O risco mais preocupante até o momento é a geração do APK e tal risco é ligado tanto ao risco de trabalhar com uma equipe maior (equipe dos quatro app's dentro do Integra) quanto ao risco do caro deploy dos nossos microsserviços. É muito importante que o scrum master da equipe passe a verificar a possíbilidade da separação dos apps quanto, também, a possibilidade da equipe dividir entre todos os membros o valor do deploy dos microsserviços.

  Concluí-se então que o trabalho continua caminhando e que alguns grandes riscos passem a ser mitigados antes que se tornem um gargalo muito grande.