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 |
Os riscos indentificados nesta sprint foram:
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.
Pontos Positivo | Pontos Negativos | Soluções |
---|---|---|
Equipe trabalhando constantemente | Equipe um pouco dispersa | Scrum Master voltar a trabalhar com mais afinco |
Mesmo com a difuculdade do projeto aumentando a equipe continua a fazer entregas | Scrum Master trabalhando com menos afinco | Equipe procurar ter um pouco mais de foco |
- | Reunião de entrega de sprint dispersa | Diminuir um pouco o tamanho das issues (dividir melhor as issues) |
- | Problemas com as imagens nas notificações | - |
- | Problemas pessoais afetando a produtividade | - |
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.
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!
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.
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.
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.