Resultados da Sprint 4
A versão da release da sprint pode ser vista em: versão v0.6.0
Nesta sprint mais uma vez não foram cumpridas todas as histórias planejadas. Isso impacta diretamente no planejamento da sprint posterior. Entretanto nessa sprint o time conseguiu fragmentar mais as histórias.
Durante essa semana de trabalho foi feito um acordo de que durante essa sprint seriam realizadas histórias menos complexas em relação às duas sprints passadas, em decorrência de boa parte do time de desenvolvimento não poder focar na matéria no começo da sprint. Fato esse que pode ser verificado na agenda de pareamento, onde boa parte dos times marcaram horários só a partir de quarta-feira.
Entretanto, ainda que fossem botadas histórias mais simples, um membro de uma das duplas pediu para ficar com mais pontos que o resto do time pois teria tempo livre para investir na matéria durante a semana. Mas esse membro juntamente com a sua dupla de pareamento não conseguiram entregar nenhuma de suas histórias.
Por fim, temos outra história que não foi entregue pois dois dos membros do grupo que foram colocados juntos em um pareamento viajaram para o TECO(Torneio de engenharias do Centro Oeste). E deixaram a matéria totalmente de lado ocasionando mais um atraso para o grupo.
Como já foi citado no item anterior, a maior parte dos membros do time não tinham tempo para se dedicar a matéria no começo da semana. Isso pode ser visto melhor na agenda de pareamento, onde a equipe só começou trabalhar a partir de quarta-feira.
Pode-se ver que duas das duplas não marcaram horários para pareamento durante a semana. Entretanto uma delas entregou todas as histórias designadas, o que pode-se dizer que ambos trabalharam bem durante a semana. A outra dupla viajou para o TECO(Torneio de engenharias do Centro-Oeste) e deixou a equipe durante uma semana.
Agora em relação às duplas que marcaram horários para parear, elas cumpriram conforme o necessário os seus horários.
O burndown dessa sprint foi bastante comprometido, novamente pelo fator de a equipe não poder se dedicar à matéria no início da semana. Fazendo então a queima de pontos só começar a ocorrer à partir do final da sprint.
Por fim, pode-se ver que restaram 25 pontos não queimados na sprint, entretanto desses 25 pontos, 17 já estão muito bem encaminhados e só não foram contabilizados pois passou-se o tempo para se fazer o Pull Request para a sprint. Por fim, temos 8 pontos que nem foram iniciados, novamente em decorrência à dupla que viajou para o TECO.
Primeiramente, é importante dizer o motivo de se adotar um quadro de gráfico de commits. O principal motivo para se começar a mostrar esse gráfico é que no escopo da matéria onde temos sprints de uma semana, onde muito raramente os alunos tem uma dedicação total para a disciplina em decorrência de outras matérias, fica muito difícil se ter um burndown como a professora Carla requer. Pois muita das vezes temos histórias não tão simples, que possivelmente só serão completas no final da sprint.
Observando esses fatores, o grupo de GPP resolveu adotar o gráfico de commits para conseguir mostrar melhor para os avaliadores da disciplina que o trabalho vem sendo desenvolvido durante toda a sprint e não só no final da mesma.
Assim como dito nos itens anteriores, pode-se ver novamente aqui um relato de que o trabalho da equipe começou a ficar mais denso apenas após a quarta-feira.
O velocity da equipe se manteve estável em relação às ultimas sprints. Entretanto, possívelmente ele irá aumentar um pouco na próxima sprint por conta das histórias que estão relativamente prontas, e só não foram entregues por conta de não terem sido feito os pull requests dentro do tempo.
O nível de conhecimento dos membros se manteve estagnado em relação à sprint 3. Um dos principais motivos dessa estagnação é alguns membros se menosprezarem. A partir daí o que acontece? Quando um membro que claramente sabe mais acerca de um determinado assunto se auto-classifica de uma forma baixa, os outros membros do grupo acabam por achar que não devem crescer o seu quadro de conhecimento para um nível acima, ultrapassando esses membros que possivelmente saibam mais. Com esse acontecimento, muito dos membros acharam que seria prepotência julgar-se melhor nesses conhecimentos.
Um fator muito importante de se visualizar tanto ao final como no decorrer da sprint é o que deu errado na sprint anterior, assim como suas melhorias propostas. Essas informações faz com que o Scrum Master tenha locais específicos para agir e garantir uma melhora. Logo serão elencados abaixo os principais pontos negativos e melhorias propostas da sprint 3, assim como as ações tomadas.
-
Javascript: No planejamento da sprint foi designado que uma dupla trabalhasse especificamente em uma história para testar js. Para que esse conhecimento possa ser trazido para a equipe e depois disseminado. Além disso, para a sprint 4 foram planejadas poucas histórias que envolviam algo mais complexo se tratando de JS.
-
Mudança de requisitos constante por parte do cliente: Foi explicado para o time de MDS a importância de se adaptar e responder às mudanças no projeto. E que o ágil preza por isso. Logo mudanças nos requisitos se tratando de um escopo ágil é algo normal.
-
Reclamações constantes: Foi feito um momento de "lava roupa" durante a reunião de planejamento onde os membros disseram quais os pontos que mais influenciavam em seu ânimo. Como um dos pontos citados foi este, espera-se que os membros que estavam presentes e participaram desse momento se portem melhor em relação ao grupo nos quesitos apontados.
-
Equipe não está madura ainda: GPP explicou para MDS durante a reunião sobre a maturidade dos mesmos. Para que eles entendam o que esperamos deles. E que os mesmos possam crescer mais e mais com a matéria.
-
Algumas melhorias propostas não estão sendo feitas: Foram feitas ações em relação à todas as melhorias propostas.
-
Mudanças no critério de aceitação no decorrer da Sprint: Foi marcado uma reunião extra com o cliente, conforme dito nas melhorias.
-
Dojô de javascript: A equipe de GPP foi atrás de uma pessoa capacitada em JavaScript, primeiramente conseguimos um aluno que se dispôs a ajudar-nos, mas o mesmo não deixou de ter disponibilidade para o dia ao qual estava marcado, por fim não conseguimos arranjar alguém devido ao fim do semestre.
-
Começar a reunião de retrospectiva e priorização de backlog mais cedo: As reuniões foram feitas em dias diferentes.
-
Alterar dia da reunião com o cliente: A equipe marcou uma reunião adicional a cada quinze dias com o cliente. Para sanar os problemas decorrentes à reunião ser feita no meio da sprint. Nessa nova reunião serão feitas toda a priorização de funcionalidades.
-
Atualizar quadro físico e wiki: Existe um membro de MDS que cobra constantemente de seu grupo este fato, conseguindo que o quadro seja atualizado mais assiduamente. Entretanto o quadro não está sendo totalmente atualizado por conta de dois membros viajarem.
-
MDS participar da reunião com o cliente: Essa melhoria foi feita, nas duas últimas reuniões com o cliente trouxemos membros de MDS para conhecer o mesmo, e terem uma visão melhor de como é o relacionamento com o cliente.
-
Pontuar todo o backlog: Feito.
-
Atualizar a folha de estilo: Melhoria está sendo feita constantemente.
-
Realizar o planejamento e critérios de aceitação com mais calma: Melhoria foi feita, durante a reunião de planejamento da sprint 4.
-
Colocar história solitária para alguns membros: Não foi feito, entretanto foi pensado em um pareamento justamente por conta de dois membros irem viajar para o mesmo lugar no meio dessa sprint.
-
Escrever critério de aceitação durante a reunião: Melhoria foi feita, durante a reunião de planejamento da sprint 4.
O relatório de gamificação se encontra na seguinte página Relatório de Gamificação da sprint 4.
Como chegamos na metade da Release II, a equipe de GPP resolveu passar um questionário ao cliente, para o mesmo fazer uma análise em relação ao projeto até então. Pode-se ver abaixo as perguntas e respostas do mesmo:
Com base nos resultados levantados, pode-se perceber que o time está cumprindo as expectativas do cliente.
