+Monitoria

+Monitoria

  • Requisitos
  • Docs
  • Sprints

›Sprint 2

Sprint 0

  • Planning
  • Review

Sprint 1

  • Planning
  • Review

Sprint 2

  • Planning
  • Review

Sprint 3

  • Planning
  • Review

Sprint 4

  • Planning
  • Review

Sprint 5

  • Planning
  • Review

Sprint 6

  • Planning
  • Review

Release 1

  • Release 1 Review

Sprint 7

  • Planning
  • Review

Sprint 8

  • Planning
  • Review

Sprint 9

  • Planning
  • Review

Sprint 10

  • Planning
  • Review

Sprint 11

  • Planning
  • Review

Sprint 12

  • Planning
  • Review

Sprint 13

  • Planning
  • Review

Release 2

  • Release 2 Review

Post Mortem

  • Post Mortem

Review da Sprint 2


1. Resumo


  • Período: 01/04 - 07/04
  • Scrum master: Lucas Siqueira
  • Product Owner: Caio Oliveira
  • Devops: Matheus Rodrigues
  • Arquiteto: Lucas Macedo


2. Resultados da sprint


2.1 Fechamento da Sprint


TarefasStatusPontos
Descrição da metodologiaConcluida2
Configurar ambiente de desenvolvimento do back-endConcluida5
Documento de arquiteturaConcluida8
Folha de estiloConcluida2
Prototipo de alta fidelidadeConcluida5
Documento de Abertura do ProjetoConcluida2
Refatorar Github PagesNão concluida5
PriorizaçãoNão concluida1
Documentos do scrum master sprint 2Concluida1
Dojo de PytestConcluida3
Plano de TempoNão concluida2

Pontos Planejados: 36

Pontos Concluídos: 28

2.2 Retrospectiva


MembroPontos PositivosPontos NegativosSugestões de melhoria
Lucas SiqueiraMaior entendimento da equipe em relação às metodologias ágeis, boa prototipação do produto, conclusão do backlog, importantes decisões tomadas.Dívidas continuaram como dívida e as entregas não foram constantes.Maior comprometimento na realização das tarefas.
Lucas MacêdoFechamento do backlog do produto, ambientes configurados para início da codificação.Falta de comprometimento da equipe de EPS que deixou as mesmas histórias como dívida, demora na definição da logo e do novo nome do projeto.Maior comprometimento da equipe de EPS.
Caio OliveiraFechamento do backlogFalta de proatividade da equipe de MDS e dívidas não resolvidasMaior comprometimento para acabar com dívidas
Matheus RodriguesFechamento do backlog e ambientes configuradosDívidas não resolvidasFoco nas reuniões
Moacir JuniorDojo de testes, aprendi a utilizar o figma, ótimo pareamento no desenvolvimento do protótipo.Dependência entre as issues e falta direcionamento na realização das tarefas.Deixar menos dívidas.
João PedroAgora tenho um entendimento maior do projeto, todo mundo evoluiu em relação às metodologias ágeis, aprendi testes em python, bom engajamento nas dailysFalta de tempo disponível para execução das tarefasDividir melhor o tempo para a realização das tarefas
Matheus CristoAprimorei minhas técnicas de documentação, compreendi os padrões de codificação.Demora nas entregas.Melhor administração do tempo e comprometimento na entrega das tarefas.
Renan CristyanDojo de teste, realização da folha de estilo, e maior entendimento da arquitetura na realização do documento.Pouca efetividade no pareamento do desenvolvimento do documento de arquitetura.Mais objetividade e diminuir brincadeiras durante os pareamentos.
Lucas AlexandreAdquiri conhecimento básico em teste, ao fazer o protótipo elevei meu conhecimento acerca do projeto, tive um pareamento efetivo na realização do protótipo.Dependência do PO na realização do protótipo.Nenhuma.

3. Quadro de conhecimento ao fim da sprint


Ilustração do Quadro de Conhecimentos

4. Burndown


Burndown Sprint 2


5. Velocity


Velocity Sprint 2


6. Engajamento nas dailys


Engajamento Dailts Sprint 2


7. Feedback do Scrum Master


7.1 Análise dos riscos


Riscos ocorridos durante a sprint:

R07 - Entregas atrasadas:

Das dívidas anteriores, apenas uma foi cumprida, e as outras 2 se mantiveram como dívidas, e tivemos mais uma dívida dessa sprint, referente a refatoração do github pages, ocasionadas devido ao mal planejamento do tempo ao decorrer da sprint.

As ações tomadas foram: Definir uma meta de priorizar essas tarefas logo no início da sprint, porém os pareamentos vão se manter.

R08 - Dependência das atividades:

Ocorreu a dependência do backlog para a realização da priorização e da descrição das histórias no documento de arquitetura, como era uma tarefa da issue do plano tempo, estava atrasada desde a sprint anterior.

As ações tomadas foram: Realizar o backlog em paralelo ao documento de arquitetura, e ao finalizar o backlog foi feito o tópico que estava faltando. Em relação à priorização não teve nenhuma ação tomada ao longa da sprint, porém como o backlog está pronto ela já pode ser feita.

7.2 Análise geral


Nessa sprint decisões importantes foram tomadas, a partir de uma avaliação de todo o grupo junto ao Product Owner foi definido que com as mudanças no escopo do projeto não teria mais sentido chamá-lo de Hora da hora, sendo assim definido um novo nome: +Monitoria, junto ao nome foi definida a logo do produto.

Outra definição extremamente importante da sprint foi o backlog, porém a demora na realização deste documento ocasionou na dívida do plano de tempo e da priorização, sendo que ele era um dos critérios de aceitação no desenvolvimento do plano de tempo e que para que a priorização ocorresse necessitava das histórias definidas, essa demora se deu ao fato da indisponibilidade do Product Owner ao longo da sprint.

Analisando o burndown, pode-se notar que a equipe não conseguiu ser produtivamente ágil ao longo da sprint, visto que a maioria das tarefas foi concluída no último dia da sprint e que não conseguimos concluir todas as atividades planejadas, porém a equipe se mantém unida e comprometida com o projeto, sempre tentando se ajudar á concluir as tarefas.

Em relação a comunicação da equipe, foi iniciado a documentação de engajamento das dailys. Nota-se que o engajamento está bom, porém alguns membros esqueceram de responder alguns dias. Outro ponto a comentar em relação a comunicação é que durante a semana ocorreu uma reunião de alinhamento com toda a equipe para atualizá-los decisões que estavam sendo tomadas.

Analisando o quadro de conhecimento nota-se que a equipe está cada vez mais se familiarizando com a metodologia adotada e que o dojo de testes em python foi extremamente produtivo, visto que ocorreu evolução em relação a esse conhecimento por todos.

Em relação ao velocity, percebemos que estamos planejando mais pontos do que estamos conseguindo entregar, visto isso, a próxima sprint será planejada com menos pontos, sendo prioritário a conclusão das dívidas que são as mesmas desde a sprint 1.

Apesar dos pontos citados, tem-se que essa sprint foi de extrema importância para o início do desenvolvimento do projeto, pois ocorreu a finalização do levantamento de requisitos junto à finalização da prototipação do produto, ocorreu a definição do backlog do produto, a priorização está encaminhada e será concluída o mais rápido possível, e o ambiente está configurado para dar início a codificação.

← PlanningPlanning →
  • 1. Resumo
  • 2. Resultados da sprint
    • 2.1 Fechamento da Sprint
    • 2.2 Retrospectiva
  • 3. Quadro de conhecimento ao fim da sprint
  • 4. Burndown
  • 5. Velocity
  • 6. Engajamento nas dailys
  • 7. Feedback do Scrum Master
    • 7.1 Análise dos riscos
    • 7.2 Análise geral
Nossos repositórios
+Monitoria Docs+Monitoria FrontEnd+Monitoria API gateway+Monitoria API monitorias
Copyright © 2019 +Monitoria