Resultados da Sprint 3
1. Indicadores de Qualidade do Processo
- 1.1 Fechamento da Sprint
- 1.2 Agenda de Pareamento
- 1.3 Burndown
- 1.4 Gráfico de commits
- 1.5 Velocity
- 1.6 Quadro de Conhecimento
- 1.7 Melhorias em relação a Sprint 2
- 1.8 Retrospectiva
2. Indicadores de Qualidade do Código
A versão da release da sprint pode ser vista em: versão v0.5.0
Nesta sprint a agenda de pareamento não foi realizada devido a dificuldade de encontrar horários, pois como era semana universitária e não houve aula os membros organizaram seus horários de acordo com o que tinha planejado anteriormente tornando um pouco mais difícil exigir horários em comum. Apesar da não conclusão de todas as histórias o Scrum Master ficou em contato constante com as duplas para saber se estavam fazendo e como estavam realizando as histórias. As duplas mostram-se mais maduras pois conseguiram paralelizar bastante o trabalho por não estarem presente no mesmo local tiveram que trabalhar com tarefas em paralelo.
Como nesta sprint três histórias planejadas não foram entregues, o burndown ficou abaixo do que o esperado. Entretanto o que vem sendo visto no burndown não é de fato o que a equipe está trabalhando, isso ocorre devido aos membros da equipe não estarem de fato trabalhando como se estivessem no mercado de trabalho totalmente dedicado ao serviço, sem ter que se preocupar como todas as demais matérias da faculdade. Esses motivos já foram debatidos em sala com a professora Carla Rocha. As histórias que ficam para o final da sprint é devido aos membros estarem aprendendo a tecnologia e que só é considerado história pronta as que atendem todos os critérios de aceitação e foram testadas. Esse fato mascara um pouco a produtividade da equipe durante a semana quanto a pesquisas e até o entendimento da funcionalidade, dando uma falsa sensação que a equipe só produzem no final do sprint o que não está acontecendo.
Há de fato um equívoco no planejamento pois algumas histórias foram subestimadas quanto a sua dificuldade e por isso ficaram de dívida técnicas.
A maioria das histórias foram entregues, algumas não foram entregues devido a não atenderem os critérios de aceitação, ou o pull request ter sido realizado após o fim da sprint. Essa sprint foi um risco que a equipe assumiu em pegar a maior quantidade de ponto possível para tentar mitigar a parte que era considerada a mais crítica do projeto, que se trata da prescrição. Essa parte é onde todos os pontos do projeto se encaixam e precisa de uma maior atenção da equipe, pois o próprio cliente falou que o mais importante no sistema é conseguir realizar uma prescrição médica. As histórias que não foram entregues ficaram de dívida técnica para a próxima sprint.
O nível de conhecimento dos membros melhorou, principalmente em relação a parte do front-end do projeto, tanto HTML/CSS e JavaScript. Ainda é necessário a equipe adquirir muita maturidade quanto a JavaScript, mas aumentar um pouco o conhecimento mostra que a equipe está estudando e indo atrás de algo que será fundamental para o projeto.
Desânimo da equipe:
Foi realizado um questionário e designado uma parte da reunião para os membros exporem os seus sentimentos em relação à matéria, ao projeto e aos fatores que podem influenciar em seu ânimo. Segue abaixo o link para visualizar o questionário.
Algumas atividades básicas do SCRUM não estão completas:
Hangout pelo Scrum Master mesmo na semana universitária, foi feito uma retrospectiva, review e planejamento mais detalhado. Por fim, foi feito um avanço em relação as atividades como fechar a pontuação do backlog geral.
Dificuldade de realizar o login nos testes:
Dúvida sanada através da gestão de conhecimento dentro da equipe. JavaScript
Necessidade de realizar retrabalho no projeto:
Foi explicado para o grupo que no ágil é normal refatorar, logo essa parte de retrabalho não é tão impactante, embora frustrante as vezes.
Mudança de requisitos por parte do cliente:
As reuniões com o cliente ocorriam sempre as terças-feiras, por esse fato era mostrado para ele o que havia sido feito na sprint anterior e já era priorizado o que seria feito na próxima sprint. O que estava acontecendo é que a equipe estava tentando aplicar as alterações solicitadas pelo cliente durante a sprint. Foi explicado ao cliente que as alterações não ocorreriam no decorrer da sprint e sim na próxima sprint que fosse planejada.
Comunicação entre as equipes de GPP e MDS:
A equipe de GPP vem buscando tentar trazer mais o sentimento de TIME e não apenas um grupo de trabalho. Embora os perfis dos alunos em geral não ajudem nessa busca.
Histórias muito complexas:
Fragmentação das histórias complexas em histórias menores e mais simples de serem alcançadas.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 3.
Ao final dessa sprint estamos com o projeto sendo ajustado em relação aos indicadores da EVM. Neles podemos observar que ao término dessa sprint temos que o valor agregado do projeto ainda está abaixo do planejado inicialmente, porém está mais próximo ao esperado.
A Variação do Prazo e o Índice de Desempenho de Prazo demonstram que conseguimos recuperar o atraso existente no projeto. Onde as dívidas decorrentes da sprint passada foram concluídas e assim fazendo com que esses índices tenham seu valor próximo ao planejado novamente.
Vale-se ressaltar que o valor agregado não se igualou ao valor planejado porque algumas histórias planejadas para esta sprint não foram concluídas no prazo.
Durante a sprint 3 o ocorreu a semana universitária, foi uma semana que o time não teria aulas logo poderia desenvolver mais funcionalidades. Na reunião de retrospectiva e planejamento da sprintque ocorreu na sexta-feira(20/10/)time discutiu e entrou em um acordo que usaríamos o tempo extra de semana universitária para desenvolver as principais funcionalidades. Mesmo com as histórias sendo entregues com algumas dívidas técnicas, a decisão tomada por realizar uma sprint com uma maior quantidade de pontos mostrou bons resultados, pois a equipe deu enfoque muito grande para o core da aplicação que era a prescrição médica. O motivo de focar nesta parte core da aplicação foi uma sugestão da professora Carla que o grupo mitigasse os maiores riscos do projeto.
Uma melhora nesta sprint foi a capacidade de realizar trabalhos remotamente o que foi um ponto muito importante e isso se deve ao tempo de trabalho entre os membros, o que mostra que a maioria do time é um time coeso, realizando grande parte das atividades atribuídas. Algumas histórias não foram entregues, uma delas se deu ao fato de uma pessoa da dupla ter viajado e o membro que ficou sozinho não conseguiu realizar os testes da história a tempo de entregar na sprint.
Um ponto negativo da sprint foi a dependência de algumas histórias, que seriam as histórias de prescrição, pois todas elas tinham muitos pontos só que a equipe pensou em cada história focar em um ponto específico da história e nos merges da sprint tudo seria integrado. As histórias evoluíram e conseguiram ser entregues, entretanto alguns bugs ou dívidas técnicas foram gerados. Essas dívidas se deve na maioria das vezes por conta da tecnologia JavaScript que foi utilizada intensamente e a maioria dos membros não possuíam conhecimento.
