Fechamento da Sprint

Backlog da Sprint

ID História Status Pontos
ISSUE #8 Treinamento de tecnologias Fechado 3
ISSUE #9 Treinamento de Chatbot Fechado 3
ISSUE #10 Elaboração do TAP Fechado 5
ISSUE #11 Elaboração do EAP Fechado 5
ISSUE #12 Definir tecnologias a serem utilizadas Fechado 2
ISSUE #13 Criar documento de Metodologia Fechado 1
ISSUE #14 Documentar Sprint 0 Fechado 2
ISSUE #15 Definição da arquitetura inicial Fechado 2
ISSUE #16 Elaborar documento de visão Fechado 5
ISSUE #17 Elaborar documento de arquitetura Fechado 5
ISSUE #18 Criar fluxograma versão 1.0 Fechado 5
ISSUE #19 Dockerizar o ambiente Fechado 3

Pontuação Final

  • Pontuação Total: 41 Pontos Planejados
  • Débitos Técnicos Adicionados: 0 Pontos
  • Pontos Concluídos: 41 Pontos Concluídos

Débitos Técnicos de Sprints Anteriores

  • Não houveram débitos técnicos para pagar nesta sprint

Débitos Técnicos Gerados

  • Não foram gerados débitos nesta sprint

Retrospectiva

Pontos Positivos

  • Tem lanche
  • A gente conseguiu se comunicar bem
  • Issues foram completadas
  • Usamos bem as issues (estamos nos comunicando nas issues)
  • Iuri monopolizou arquitetura (ajudando quem não pode trabalhar no momento)
  • Conseguimos definir melhor o projeto (estava muito abstrato)
  • Não houveram muitos empecilhos
  • Issues finalizadas
  • Conseguimos fechar tudo
  • Boa comunicação
  • Fechamos tudo
  • Apesar da falta de conhecimento sobre documentação, MDS conseguiu produzir bem
  • Iuri trabalhando muito
  • Ajuda do Guilherme no doc de arquitetura
  • Diagrama de Caso de Uso foi útil
  • Ajuda externa
  • Descobrimos muita coisa sobre EPS que não sabíamos
  • Aprendendo coisas legais
  • Docker tá indo (ainda não sei pra onde)
  • MDS conseguiu fazer os documentos
  • Esforço de MDS, EPS deixou a desejar ao entregar a parte completa

Pontos Negativos

  • Falta de conhecimento
  • PR errados
  • Iuri monopolizou o conteúdo
  • Sábado a tarde
  • Monopolio de trabalho pode atrapalhar parte da equipe
  • Comunicação entre EPS e MDS, principalmente no doc de Arquitetura
  • Muito trabalho para o Iuri (tinha mais tempo livre, e trabalhou mais)
  • Falta de salas pro Dojo
  • Iuri trabalhando
  • Começamos errado na metodologia (levantamento de requisitos não foi feito direito antes da arquitetura)
  • Arquitetura começou mal, pois começou sem bom conhecimento das tecnologias
  • Mais integração no time de EPS (todos estarem presentes na reunião, e conseguir resolver problemas o mais rápido possível)

Melhorias

  • Pareamento sem competição, e sim como time (definir bem a sua parte e “ajudar” o outro no tempo que sobrar)
  • Melhorar comunicação entre EPS e MDS
  • E melhorar divisão do trabalho (e respeito a divisão)
  • Salas para o Dojô
  • Falta de organização ao criar documentação
  • Ler mais o PMBOK
  • Melhorar metodologia
  • Construir backlog da Sprint antes da reunião

Burndown

Burndown

Velocity

Velocity

Quadro de Conhecimento

Quadro de conhecimento

Riscos

Risco Ação Preventiva Ação Reativa
Dificuldades da equipe com as novas tecnologias inseridas Seleção de alunos experientes para aplicação de treinamento. Realização de treinamento sobre tecnologias.
Elaboração da arquitetura do projeto Estudo das tecnologias que integrarão a arquitetura Reuniões da equipe de EPS para definição das tecnologias e arquitetura
Alteração do escopo Documentar e refinar de forma constante os requisitos Planejar corretamente a sprint e se manter atualizado quanto às novas funcionalidades que serão adicionadas ao bot

Burndown de Riscos

Burndown de Riscos

Resumo pelo Scrum Master

Sprint focada no treinamento de tecnologias e criação de documentos. A equipe conseguiu entregar todas as atividades propostas. A sprint foi um sucesso.