Resultados da Sprint 1
1. Indicadores de Qualidade do Processo
- 1.1 Fechamento da Sprint
- 1.2 Agenda de Pareamento
- 1.3 Burndown
- 1.4 Velocity
- 1.5 Quadro de Conhecimento
- 1.6 Retrospectiva
2. Indicadores de Qualidade do Código
Todas as histórias planejadas para a sprint foram concluídas. As histórias planejadas para a sprint foram feitas principalmente pela dependência das outras histórias levantadas, como consequência houve a consolidação do conhecimento da equipe em relação ao desenvolvimento de CRUD's (Create, Read, Update e Delete) na tecnologia utilizada.
Percebe-se que a agenda de pareamento surtiu um efeito positivo para a conclusão das histórias. Mesmo que alguns pareamentos planejados não tenham sido feitos, a agenda, de forma geral, foi cumprida durante a sprint. Esses horários não cumpridos foram replanejados durante a sprint e executados em outros horários.
Observa-se um gráfico mais coeso em relação ao anterior. Mesmo com o gráfico mais condizente com o trabalho realizado, o progresso do desenvolvimento das funcionalidades não está representado por este gráfico. O gráfico burndown só tem progresso quando uma história é entregue por completo, ou seja testada, além disso e necessário a aprovação da história, tal aprovação não é instantânea e exige um tempo relevante para análise da funcionalidade. No contexto em que o grupo se encontra não é possível que essa análise seja instantânea e nem mesmo que uma história seja entregue nos dias iniciais da sprint.
Como todas as histórias foram entregues e o grupo de Gerência de Projeto começou a participar ativamente do desenvolvimento do projeto o velocity aumento em relação ao anterior. Mesmo com o aumento do velocity não é possível afirmar que este indicador está em um estado bom ou ruim, visto que o é buscado que o velocity fique em um estado de entropia, ou seja, busca-se uma constância do velocity em relação a todas as sprints.
O nível de conhecimento dos membros melhorou, principalmente em relação aos testes que era uma das maiores dificuldades do time. Outro bom resultado da sprint foi a maior confiança em relação ao git por parte dos integrantes.
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.
-
Membros de Gerência ausentes: Os membros da equipe de Gerência de Projeto se mantiveram ausentes na sprint passada, por conta do foco em outra matéria. Durante a fase final da Release I a equipe quase que focou exclusivamente no projeto, deixando acumular conteúdo de outras disciplinas, principalmente Desenho de Software. Por este motivo, os membros de GPP ficaram com sobrecarregados com as demais disciplinas. Após uma iteração tanto quanto conturbada, a equipe de Gerência de Projeto voltou o foco, novamente, para a projeto.
-
Sprint atrasada: A sprint 0 foi iniciada tardiamente, pelo fato do fim da Release I e o foco dos integrantes de GPP estarem voltados a outra disciplina. Com a volta das atenções do grupo de GPP para o projeto a iteração começou na data programada.
-
Desorganização da Sprint: Como citado no tópico acima, a equipe de GPP estava com foco em outra matéria causando uma desorganização da iteração, visto que o grupo de MDS não tem experiência com a metodologia. Com a volta da concentração de GPP para o projeto esse problema foi controlado.
-
Dificuldade de parear por incompatibilidade de horários: Uma das maiores dificuldades encontradas na sprint passada foi a dificuldade de parear por conta da incompatibilidade de horários, por esse motivo foi criado a agenda de pareamentos, onde os integrantes do time indicam o horário livre para que se possa parear, ou seja, é assumido um compromisso entre a dupla que será cobrado pelo Scrum Master. Essa intervenção surtiu um efeito positivo com um cumprimento maior do pareamento.
-
Entrega das histórias no fim Sprint: Esse ponto negativo esta estritamente relacionado com o ponto acima, dessa forma a agenda de pareamento foi criada para mitigar essas falhas. O efeito foi positivo, já que a entrega das funcionalidades foi feita de forma gradativa se comparada com a iteração anterior, isso é evidenciado no burndown.
-
Membro de MDS ausente: Observou-se que um membro de MDS voltou a ficar ausente na iteração passada, não entregando uma história delegada a ele e nem mesmo participou da reunião de revisão/retrospectiva da sprint. Com o objetivo de contornar esse ponto falho, a equipe de Gerência de Projeto delegou a esse indivíduo o pareamento com um dos membros da equipe de GPP, que ficou responsável por cobrar e observar o comportamento do integrante em questão. Essa medida foi bem sucedida, o membro participou de todos os pareamentos marcados cumprindo o que foi planejado.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 1.
O relatório de gamificação se encontra na seguinte página Relatório de Gamificação da sprint 1.
Durante a sprint 1 o time se mostrou capaz de realizar grande parte das atividades atribuidas. Todas as histórias foram feitas e, ao contrário da iteração anterior, novas funcionalidades foram integradas ao sistema.
Dos pontos positivos da sprint vale destacar algumas como o planejamento conjunto da sprint, segmentação do trabalho durante a sprint, o funcionamento parcial da agenda de pareamento, o amadurecimento da equipe e o aprendizado das tecnologias e das metodologias utilizadas.
Mesmo que todas as histórias tenham sido entregues, algumas atividades características do Scrum, como o daily meeting, deixaram a desejar, muito pelo fato da dificuldade do encontro presencial e este ser feito via Telegram. Outros pontos negativos foram a dependência de alguns membros em relação ao par no pareamento, dificuldade de seguir política de branches e principalmente a dificuldade de comunicação entre os membros da equipe e com o cliente. Estes dois ultimos são os mais prioritários.
