Resultados Sprint 3
Sprint que marca as primeiras entregas de software, a dockerização dos repositórios do projeto, a formalização de métricas e indicadores que serão utilizados buscando qualidade, e a finalização da parte arquitetural do projeto.
Fechamento da Sprint
| Issue | Status | Pontos |
|---|---|---|
| US19 - Fazer o upload de uma nota fiscal | Concluída | 13 |
| US16 - Pesquisar o padrão de notas fiscais | Concluída | 8 |
| Refatorar Protótipo | Concluída | 2 |
| Refinar Documento de Arquitetura | Concluída | 1 |
| Criar Organização | Concluída | 0 |
| Criar Repositórios Dockerizados | Concluída | 3 |
| Estimar Custos | Concluída | 3 |
| Elaborar o Diagrama de Dados | Concluída | 2 |
| Criar o Documento de Resultados da Sprint 2 | Concluída | 0 |
| Criar o Documento de Planejamento da Sprint 3 | Concluída | 0 |
| Criar o Plano de Medição | Concluída | 2 |
| Refatorar TAP | Concluída | 1 |
| Treinamento de Flask | Concluída | 2 |
| Iniciar Roadmap do produto | Concluída | 3 |
| US31 - Criar interface gráfica para realizar upload de notas fiscais | Concluída | 8 |
| Refatorar Canvas | Não Concluída | 1 |
Pontos Planejados Concluídos: 45
Pontos de Dívida Concluídos: 3
Pontos Não Agregados: 1
Burndown
O burndown indica que as issues foram entregues tardiamente. Quase toda a equipe de desenvolvimento estava atarefada com outras disciplinas, e as provas só acabaram no final da sprint (quinta feira).
Velocity
Após o fechamento do escopo na sprint anterior, foi possível alocar mais histórias, e concluir a dívida relacionada ao escopo.
O velocity aumenta à medida que a equipe ganha maturidade, permitindo o aumento gradual da pontuação total das próximas sprints.
Riscos
Baseado no desempenho da equipe durante a semana, a probabilidade dos riscos existentes foram determinados para a próxima sprint. Os pontos foram definidos com a participação de toda a equipe, após a retrospectiva. Objetivo é tornar o monitoramento de riscos transparente para toda a equipe, e que seja possível com que todos visualizem sua evolução.
Retrospectiva
Pontos positivos aumentaram em comparação com a sprint anterior. Novos pontos negativos foram apontados, contudo, alguns deles refletem apenas dois riscos já mapeados, e os outros pontos negativos refletiram acontecimentos isolados.
Sprint Anterior
Medidas tomadas para que pontos negativos elencados na semana anterior não se mostrassem novamente:
| Ponto Negativo/Melhorar | Correção Adotada |
|---|---|
| Mais dailies presenciais, as pelo Telegram são ok, mas nem todos respondem ou respondem bem | Dailies de segunda e sexta serão realizadas via hangouts, e não mais por telegram. Terão duração de 20 minutos e começarão às 21h30. |
|
A equipe expôs pontos que se conectam com três riscos: falha de comunicação, desentendimentos entre integrantes da equipe e integração do time. As medidas acordadas envolvem maior eficiência na comunicação, através de dailies mais focadas e maior envolvimento com membros desfalcados, através de adaptação de horários para que todos possam participar de todas a decisões que serão tomadas. Com relação aos desentendimentos, a retrospectiva teve duração maior que o usual para que os pontos levantados fossem discutidos. A postura em relação ao time deve ser de respeito. |
Quadro de Conhecimento
Registros de Presença nas Dailies
| Nome | Segunda Feira | Terça Feira | Quarta Feira | Quinta Feira | Sexta Feira |
|---|---|---|---|---|---|
| Bernardo | ✔ | ✔ | ✔ | ✔ | ✘ |
| Clarissa | ✔ | ✔ | ✔ | ✔ | ✘ |
| Esio | ✔ | ✔ | ✔ | ✔ | ✘ |
| Felipe | ✔ | ✔ | ✔ | ✔ | ✔ |
| Jacó | ✔ | ✔ | ✔ | ✔ | ✔ |
| Lucas | ✔ | ✔ | ✔ | ✔ | ✔ |
| Mariana | ✔ | ✘ | ✔ | ✔ | ✔ |
| Pedro | ✔ | ✔ | ✔ | ✔ | ✔ |
| Saleh | ✔ | ✔ | ✔ | ✔ | ✔ |
| Youssef | ✔ | ✔ | ✔ | ✔ | ✔ |
Avaliação do Scrum Master
A equipe se mostra mais uma vez proativa, onde, mesmo numa semana caótica para a equipe de desenvolvimento, as histórias que eram de responsabilidade deles foram entregues. EPS, buscando qualidade, prepara repositórios para integrações contínuas, e rebusca o escopo, reduzindo seu risco de indefinição.
O burndown reflete a entrega tardia das issues, dado o cenário em que a sprint aconteceu. Para as próximas sprints, é esperado que o burndown reflita a quiema uniforme dos pontos, que, nessa sprint, foi atípica. Apesar da semana da sprint ter colidido com a semana mais cheia para a equipe (provas), praticamente todas as issues foram entregues, mostrando que a equipe está motivada e é produtiva.
Durante a sprint, uma nova issue foi adicionada, visando a capacitação da equipe de desenvolvimento e a mitigação do risco de dificuldade com tecnologias adotadas. (Flask)
Não foram identificados riscos novos no decorrer da sprint. Entretanto, um dos riscos já mapeados se mostrou bastante: ausência de membros do time. A medida de prevenção adotada se resumiu na busca de horários convenientes para que o integrante ausente participasse, e o trabalho de mitigação do risco de falhas de comunicação favoreceria sua participação objetiva.
Em comparação com a sprint anterior, foi possível perceber a melhora da comunicação entre a equipe, fazendo com que o risco de falha de comunicação diminua. A escrita do backlog do produto completo com a participação total da equipe, esclareceu pontas soltas no escopo, favorecendo a diminuição do risco de indefinição de escopo.
A dificuldade com tecnologias ainda é um risco com probabilidade alta, dado que nem todos os membros da equipe entraram em contato com as tecnologias durante a sprint.
O final da sprint marca acertos e erros por parte das equipes de MDS e EPS. Erros como MDS começar tardiamente as issues, e EPS por revisá-las tardiamente, entre falhas como atrasos nas reuniões, principalmente nas dailies, sobrecarga de membro por conta de ausência do parceiro, e falta de atenção com as pipelines do ZenHub. Dentre os pontos positivos, vale destacar a comunicação da equipe, o empenho em entregar as tarefas mesmo numa semana caótica, os treinamentos de qualidade, e os planejamentos rápidos e eficientes.