Resultados da Sprint 5
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 0
- 1.8 Retrospectiva
2. Indicadores de Qualidade do Código
A versão da release da sprint pode ser vista em: versão v0.7.0
Novamente, nessa sprint não foi possível a entrega de todas as histórias pestanejadas e dívidas técnicas geradas em iterações anteriores. Algumas histórias não foram possíveis de se entregar dado a dificuldade de integração com o ramo principal a tempo do termino da sprint, no entanto, as histórias já estavam bem encaminhadas.
Uma das histórias planejadas não foi entregue pelo fato de um membro específico ter viajado, tal viagem foi informada porém a viagem ocorreu antes do previsto. Portanto, como o membro não tinha acesso a internet na localidade em que estava, essa não pode ser entregue.
Observa-se que as principais histórias relacionadas ao chat foram entregues, muito pelo fato de serem mais simples em relação as funcionalidades vinculadas a prescrição. Outro fato a se ressaltar é que a principal funcionalidade, de adição de via dinâmicamente, foi replanejada durante a sprint durante a iteração por conta de sua complexidade.
A equipe observou que a agenda de pareamento não estava sendo seguida pelos integrantes, e por isso, se mostrou ineficaz em nosso contexto. Algumas das principais reclamações estão relacionadas a dificuldade de encontrar tempo no final de semestre onde existe uma desgaste muito grande com outras disciplinas, por conta de provas, trabalhos e afins.
Como as histórias não foram entregues pro completo o burndown reflete essa realidade. Nem mesmo as dividas da sprint anterior conseguiram ser entregues no início da iteração, sendo entregue apenas do meio pro fim da sprint.
Os commits no dia inicial da sprint representam o desenvolvimento de dividas da iteração anterior, mas mesmo assim, o burndown não representa o que foi feito, muito pelo fato de não se adequar ao contexto em que o time se encontra, com disciplinas paralelas, dificuldades de iteração presencial, tempo não condizente com o trabalho, etc.
Mesmo com os pontos observados acima é inegável uma baixa de produtividade da equipe em relação a sprints passadas. Enquanto nas duas iterações anteriores a média de commits variava em torno de 90 commits, nessa houve um decréscimo para 52.
O velocity se mantém estabilizado em torno de 35 pontos, mas existe um problema que se estende desde a sprint 2: a dificuldade de planejamento. Onde o se planeja muito e se entrega pouco, é claro a derivação de uma história em varias outras e a quantidade de dividas técnicas, mas é um erro o time não conseguir entregar o que se propõe a fazer, visto que o planejamento é feito com todos os membros e todos são ouvidos. Algumas das explicações mais condizentes é a dificuldade técnica e a demanda de outras matérias ao final do semestre.
O nível de conhecimento da equipe se manteve estagnado em relação a iteração anterior, exceto por um membro que teve melhora e uma das tecnologias. No entanto, a equipe se mostra com conhecimento razoável em relação às tecnologias utilizadas e por isso não é necessário uma intervenção para que a situação melhore, apenas conseguir difundir o conhecimento entre o time pelo pareamento.
Na tentativa de melhorar e mitigar os pontos negativos levantados na sprint anterior, foram feitas algumas intervenções sobre os pontos negativos e melhorias levantadas na retrospectiva. A imagem da retrospectiva passada se encontra logo abaixo:
-
EVM: A EVM foi um dos focos do Scrum Master, e foi concluída até a sprint em questão. Ressaltando algumas dúvidas a serem sanadas pelos coachs.
-
Resultados de sprints passadas incompletos: Os resultados das sprints foram atualizados para melhorar as decisões e dar uma visão geral do projeto.
-
Criação excessiva de histórias técnicas: Mesmo tentando não criar histórias técnicas isso não foi possível pelo fato de que surgiram alguns requisitos ou bugs, e por isso não foi completamente efetiva essa tentativa de minimizar histórias técnicas, mesmo que apenas uma tenha sido criada, visto que as outras são de iterações passadas.
-
Diminuir a criação de histórias técnicas:Na tentativa de diminuir a criação de TS's foi proposto uma divisão mais atômica das histórias, transformando funções simples em histórias separadas para que os bugs não passem despercebidos e virem TS's no decorrer do projeto. Com a adição de novos requisitos ou descoberta de novos bugs isso não será efetivo.
-
Mais rapidez na entrega dos resultados da sprint: em relação a essa melhoria foi possível a entrega das métricas de código e de processo ao fim da sprint, mas sem a análise, visto que o Scrum Master responsável pela sprint, assim como todos os outros integrantes de GPP estavam sobrecarregados com outras matérias.
-
Realizar checkup no projeto e verificar o que falta: Quanto a implementação foi feito uma listagem das funcionalidades mais importantes que faltavam e que posteriormente seria apresentada ao cliente, com o intuito de definir o escopo até o final do projeto. No entanto, quanto a documentação isso não foi feito.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 5.
Nos gráficos acima é notório que nessa sprint os indicadores da EVM ficaram abaixo do esperado. Neles podemos observar que ao término dessa sprint agregamos menos valor ao cliente do que o planejado inicialmente.
A Variação do Prazo e o Índice de Desempenho de Prazo demonstram que estamos com um déficit em relação ao prazo em relação ao planejado nessa sprint, isso é compensado nas iterações anteriores, por isso o valor agregado se mantêm acima do planejado.
Assim como as variações acima, os índices de desempenho de custo e de prazo ficaram abaixo de zero, indicando um custo maior que o planejado e que estamos atrasados, em relação a sprint em questão.
A equipe se mostrou mais confiante na iteração em questão e com isso grande parte das histórias foram entregues. Algumas histórias não foram entregues mas estavam bem encaminhadas como a US33-AddViaDynamically e a US39-ListPrescription, tendendo a ser entregue na primeira parte da sprint seguinte.
Nessa sprint notou-se um desânimo geral com o projeto causada pela desmotivação com o projeto, disciplina e faculdade além do cansaço do fim do semestre e sobrecarga da equipe. Além disso algumas histórias não foram entregues por conta de um dos integrantes ter viajado, tal viagem foi informada, porém, esta ocorreu antes do previsto.
No geral, não foi uma sprint tranquila mas a maioria dos integrantes se comprometeram com o projeto e conseguiram executar suas tarefas. Houve também, o abandono da gamificação no projeto, visto que ela não estava mais sendo efetiva e demanda muito esforço para que conseguíssemos executá-la.
Sob o ponto de vista do Scrum Master, é necessário que toda a equipe se comprometa para consigamos terminar o projeto de forma saudável sem que membros específicos se sintam sobrecarregados com as tarefas, portanto, é indispensável a transparência entre o time para que o planejamento reflita o que poderá ser feito nas iterações sem atrasos e esforço desproporcional ao tempo.
