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 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.3.0
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.
-
Começar a entregar as histórias mais cedo para melhorar o burndown: Na tentativa de resolver esse problema foi criada a agenda de pareamentos, foi uma iniciativa que funcionou parcialmente e resultou em um gráfico mais coeso em relação a iteração anterior.
-
Separar os pareamentos por horários disponíveis dos membros: Não é possível priorizar que as duplas sejam formadas por um pareamento por horário livre devido a nossa política de pareamentos para disseminar o conhecimento entre os membros do grupo, porém não é necessário que o desenvolvimento seja sempre feito durante os pareamentos.
-
Ter um maior controle dos horários em que os pareamentos serão realizados: Assim como no item anterior a agenda de pareamentos foi adotada para mitigar o problema de horários da equipe.
-
Seguir mais a metodologia ágil: Alguns rituais do ágil não foram do ágil não foram seguidos ou ignorados durante a primeira sprint como as reuniões diárias e planejamento da sprint. O planejamento da sprint foi feito com todo o time, incluindo a derivação de algumas histórias e atribuição de pontuação à elas. O daily meeting foi feito diariamente pelo Telegram, esse foi um problema apontado durante a sprint, que não foi muito esclarecedor do que as duplas estavam fazendo, bem como suas dificuldades.
-
Sprint ser mais organizada: Como a equipe de GPP não estava presente e nenhum dos membros de MDS tinham experiência com a metodologia ágil a equipe de MDS relatou desorganização da sprint. Com a volta dos membros de GPP para o projeto, observou-se que a sprint 1, em comparação com a anterior, foi mais organizada tanto em termos de planejamento quanto de execução.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 1.
Ao final dessa sprint estamos com o projeto tranquilo em relação aos indicadores da EVM. Neles podemos observar que ao término dessa sprint agregamos valor ao cliente igual ao planejado inicialmente.
A Variação do Prazo e o Índice de Desempenho de Prazo demonstram que estamos no prazo em relação ao prazo planejado do projeto, ou seja, estamos com a execução do projeto ocorrendo de forma tranquila em relação ao que foi planejado para a release.
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.
