Sprint 2
Planejamento da Sprint
Membros presentes no planejamento da Sprint |
---|
André Lucas |
Caio Brandão |
Fabíola Malta |
João Victor |
Kaique Henrique |
Matheus Vitor |
Marcos Nery |
Sannya Santana |
Vinicius Rodrigues |
Objetivo
Organização da equipe e visão do produto
Dados gerais
Data de início: 25/08/2018 Data de término: 31/08/2018
Pontos Planejados: Não se aplica Pontos Adicionados: Não se aplica Pontos totais: Não se aplica
Issues
Podem ser acompanhadas aqui.
Pareamentos
Não se aplica
Resultados
Membros presentes nas reuniões de finalização de Sprint |
---|
André Lucas |
Rogério |
Fabíola Malta |
João Victor |
Kaique Henrique |
Matheus Vitor |
Marcos Nery |
Sannya Santana |
Resultado da Revisão da Sprint
Histórias entregues
- #21 - Realizar treino sobre medição ágil
- #26 - Configurar deploy contínuo do github pages
- #23 - Reservar espaço de reunião aos sábados
- #19 - Realizar Treinamento Github Pages
Dívidas técnicas
- #10 - Elaborar indicadores e métricas
- #11 - Elaborar documento de visão
- #6 - Elaborar o termo de abertura
- #22 - Realizar treinamento de docker
História retirada do backlog
Retrospectiva da Sprint
A revisão da sprint foi realizada utilizando uma adaptação do mapa de empatia, observada na imagem a seguir:
Pontos positivos
- Conseguimos configurar a atualização contínua do docusaurus!
- Spam do github bot! Existem membros trabalhando constantemente no time
- Alguns membros deixaram para realizar o trabalho apenas no final da sprint
- Aprendizagem contínua
- Motivação, membros estão sendo constantemente assegurados.
Pontos negativos
- A visão do produto ainda não está concretizada, devido a dificuldades de comunicação com o cliente
- O time de MDS ainda possui medo de realizar commits, mesmo de documentação
- Spam do github bot! Como o time estava utilizando um grupo do telegram para comunicação e o bot estava nele, algumas informações se perderam por conta do bot
- Os critérios de aceitação de documento não estavam dispostos de forma direta, MDS não sabia a necessidade de revisão antes de aceitar o Pull Request.
- Sensação de atraso constante e instabilidade
Possíveis melhorias
- Realização de um encontro do time, para entrosamento
- Troca de ferramenta do telegram para o slack
- Não commitar na master!
- Não aceitar o próprio pull request
- Realizar trabalho constante durante a sprint
- Seguir a política de branchs
- Saber filtrar críticas externas
Análise Geral
Apesar de muitas issues não entregues, os artefatos relacionados com a visão do produto já esperava-se esse resultado, pois eles foram alocados para elicitar dúvidas que poderiam ser levadas para o cliente e ter melhor base em relação aos requisitos do projeto. Issues foram deixadas para o final da sprint, o que concretizou o risco da não entrega. O time ainda não está seguindo o processo de forma consistente.