Sprint 03 - Review

Informações Básicas da Sprint

Sprint	3
Início	05/09/2018
Término	11/09/2018
Duração	7 dias
Pontuação Total	44
Pontuação Concluída	22

Resumo da Sprint

Total de Pontos Planejados	34
Total de Pontos Planejados e Concluídos	14
Total de Pontos de dívida passada	10
Total de Pontos de dívida concluídos	8
Total de Pontos Adicionados	0
Total de Pontos Adicionados e Concluídos	0
Total de Pontos Concluídos	22
Dívida para a próxima Sprint	22

Presença na Sprint Review e Retroscpective

Membro	Presença
Iasmin Mendes
Renato Valério
Gabriel Davi
Heron Rodrigues
João Lucas Zarbiélli
Lucas Maciel
Matheus Gomes
Weiller Fernandes

Papéis

Papel	Responsável
Scrum Master	Iasmin Mendes
Product Owner	Renato Valério
Arquiteto	Iasmin Mendes
DevOps	Gabriel Valério
Time de Desenvolvimento	Gabriel Davi Silva Pereira Heron Rodrigues Sousa João Lucas Fragoso Zarbiélli Lucas Maciel Aguiar Matheus Gomes Ferreira Weiller Fernandes Pereira

Sprint Backlog

	Issue	Descrição	Pontos	Responsáveis	Status
P L A N E J A D A S	#30	Treinamento de React	2	Equipe dos App	Concluída
	#78	Recaulcular custos e valor do produto	2	Renato Valério	Concluída
	#79	Elaborar identidade visual	5	Renato Valério	Não Concluída
	#82	Reformular escopo	3	Lucas Maciel e Weiller Fernandes	Concluída
	#84	Adicionar na metodologia o método de priorização das user stories	1	Iasmin Mendes	Concluída
	#85	Adicionar uma página com o backlog no Github Pages	3	Lucas Maciel e Weiller Fernandes	Concluída
	#86	Buscar locais por nome (Backend)	8	Lucas Maciel e Weiller Fernandes	Concluída
	#33	Construir burndown de riscos	2	Renato Valério	Não Concluído
	#80	Fazer protótipo do projeto	8	Matheus Gomes e Gabriel Davi	Não Concluído
	#81	Configurar ambiente de desenvolvimento do frontend	5	Renato Valério e Equipe do App	Não Concluído
	#83	Atualizar RoadMap Geral com as histórias de usuário	2	Iasmin Mendes	Não Concluído
D Í V I D A S	#32	Fazer levantamento de riscos	3	Renato Valério	Concluído
	#33	Construir burndown de riscos	2	Renato Valério	Não Concluído
	#43	Configurar métricas com a integração contínua	5	Iasmin Mendes	Concluído
A D I C I O N A D A S	#101	Aprender a utilizar o Github Bot integrado com o Telegram	0	Iasmin Mendes	Concluída

Retrospectiva da Sprint

Pontos Positivos

Grupo alinhado
Treinamento de React foi bom
Pareamento rendeu

Pontos Negativos

Feriadão atrapalhou
Caiu muito a pontuação entregue
Faltou comunicação
Faltou proatividade

Melhorias

Mais comunicação
Mais proatividade
Mais transparência
Mais compremetimento
Comentários nas Issues
Definir melhor os pontos com os outros grupos do App

Pareamentos

Feedback

Nesta sprint houve falha de ateção da equipe e do Scrum Master. Mesmo realizando os stand-ups, ocorreu da US - Buscar local por nome ser desenvolvida enquanto o Diagrama de Classe era reformulado e nós não nos atentamos a esse detalhe, de forma que a user story foi desenvolvida em cima do diagrama antigo.
As user stories foram criadas como issues na sprint passada, e pontuadas como se o desenvolvimento da issue envolve-se o backend e o frontend. Nessa sprint, notou-se que isso é um problema, pois teoricamente, a issue US - Buscar locais, que foi implementada nessa sprint somente na parte da API, não poderia ser dada como entregue por não possuir o frontend. Visto essa situação, sentiu-se a necessidade de mudar a metodologia, e partir de então, todas as user stories devem ser criadas como épicos, de forma que nós possamos quebrar em várias atividade, sendo elas, no mínimo, desenvolvimento frontend e backend. Cabe ao Scrum Master reorganizar as user stories já registradas no repositório para essa nova abordagem.
A forma como o Sprint Review era realizado foi alterada. Até então durante o review os membros somente comentavam o que tinha sido entregue, e as dificuldades do que não foi entregue. Contudo, durante os stand-ups o Scrum Master percebeu que o grupo não estava ciente sobre atividades e decisões tomadas na Sprint 2, o que gerava dúvidas entre os membros sobre assuntos que deviam já estar alinhados entre toda a equipe. Portanto, no Sprint Review desta sprint, os membros tiveram que apresentar para os demais mebros os documentos e funcionalidade implementadas. Abrindo os arquivos e mostrando cada parte do documento ou do código confeccionado.

Burndown

Os membros de EPS foram muito sobrecarregados nas sprints passadas e, devido a essa sprint parecer um pouco mais tranquila do que as outras houve uma descpreocupação que refletiu negativamente. As issues foram deixadas para serem entregues ao final da sprint, o que acabou não dando tempo e refletindo em quase metade dos pontos do Burndown não entregues.
A issue planejada de configurar o ambiente de desenvolvimento do frontend ficou como débito devido a alguns pontos ainda não estarem acordados com os outros grupos do App.
A issue referente a prototipação representa uma boa parcela do backlog, e a mesma esta apresentando-se uma issue grande, somado a dificuldade técnica da equipe resultou na não entrega da issue.

Acompanhe mais dessa métrcia aqui.

Velocity

Até a sprint 2, a grande maioria dos pontos entregues foram referente as atividades de EPS. Na sprint 3, teve um grande diferencial de que uma parte considerável dos pontos eram de responsabilidade do time de desenvolvimento. Portanto, optou-se por uma sprint de 44 pontos, sabendo-se que o velocity era de 30 pontos contando que teríamos mais trabalho mas este estaria melhor distribuído entre a equipe. Mediante as falhas das entregas - já mencionadas na análise do Burndown desta sprint - notou-se que essa foi uma má decisão, de forma que a capacidade de produção da equipe foi superestimada.

Acompanhe mais dessa métrcia aqui.

Commits por Dia

Nesta sprint a equipe claramente deixou as entregas para o final, resultando em vários pontos de débitos para a próxima sprint.
Como relatado na Sprint Retrospective, faltou proatividade da equipe.

Acompanhe mais dessa métrcia aqui.

Quadro de Conhecimentos

Acompanhe mais dessa métrcia aqui.

Gráfico de Conhecimentos

Acompanhe mais dessa métrcia aqui.

As melhoras em HTML e CSS eram esperadas pois os membros começaram a desenvolver o prótipo utilizando destas ferramentas.
Melhoras em relação ao React atribuem-se ao treinamento de React executado durante essa sprint
A grande melhora da equipe em relação ao Ruby on Rails deve-se ao esforço individual de cada um em pesquisar e estudar mais dessa ferramenta. Os membros João e Heron estavam em atividades relacionadas ao framework, mas os demais fizeram seus estudos a parte.
A melhora quanto ao docker era esperada, pois a equipe de desenvolvimento está começando a pegar atividades das quais eles necessitem usar o docker.

Número de Pareamentos

Esta foi a primeira sprint que aplicamos o pareamento.
O pareamento foi aplicado somente para o time de desenvolvimento

Acompanhe mais dessa métrcia aqui.

Cobertura de Testes

Veja o relatório completo sobre a cobertura de testes do final desta sprint aqui.

Nesta sprint a equipe começou a desenvolver a API, mas o treinamento sobre testes ainda não havia sido realizado. Portanto, não foi exigido dos desenvolvedores que o código tivesse testes para aceitar o pull request. Dessa forma, a cobertura acabou ficando abaixo dos 90% determinados e foi aberta uma história técnica para que o código fosse testado assim que a equipe recebesse o conhecimento para tal.

Acompanhe mais dessa métrcia aqui.

Complexidade Ciclomática

Acompanhe mais dessa métrcia aqui.

Duplicação de Código

Acompanhe mais dessa métrcia aqui.

Folha de Estilo

O CodeClimate acusou 23 issues referente a folha de estilo no final da sprint, mas todas essas issues são provenientes do código auto gerado do Rails quando se cria um novo app. Algumas dessas falhas foram corrigidas durante a sprint, e as que ficaram serão corrigidas aos poucos no dercorrer do projeto.

Acompanhe mais dessa métrcia aqui.

Manutenibilidade

Acompanhe mais dessa métrcia aqui.