Resultados da Sprint 6
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 5
- 1.8 Retrospectiva
2. Indicadores de Qualidade do Código
A versão da release da sprint pode ser vista em: versão v0.8.0
Nesta sprint o time conseguiu ter um bom andamento em relação as histórias devidas da sprint passada, além de ter conseguido terminar quase todas as histórias da sprint. Duas histórias não foram completadas, a US45-PrescripeCopy e a TS20-TestJavascript, entretanto a TS20 é uma história que vem sendo arrastada há 3 sprints por conta de um membro do grupo que não faz nada (Michel), membro esse que deixou o grupo nessa sprint.
Durante toda a semana a equipe conseguiu manter um bom ritmo de trabalho, fato esse que pode ser evidenciado tanto no quadro de commits, assim como no burndown.
A sprint pode ter sido considerado um sucesso, pois as principais funcionalidades da mesma foram feitas.
A agenda de pareamento deixou de ser cobrada.
O burndown dessa sprint consegue demonstrar juntamente com o quadro de commits a intensidade de trabalho da equipe, com a mesma conseguindo matar as dívidas da sprint passada logo no começo da sprint, e conseguindo manter um bom ritmo de trabalho durante a semana.
Um fator que vinha atrapalhando o time durante o desenvolvimento das sprints seguintes em algumas sprints era o fato de as dívidas estarem consumindo um tempo um pouco grande. O que não aconteceu nesta sprint.
Por fim, pode-se ver que tivemos ainda duas histórias como dívida, entretanto como já falado anteriormente uma delas é em detrimento de um membro ter abandonado o grupo, e a outra foi pela dificuldade de implementação da mesma, mas esta está bem encaminhada.
Com o nosso gráfico de commits pode-se ter uma idéia melhor de como se distribuiu o trabalho durante toda a sprint. Como esperado, tem-se um volume maior de trabalho no final da semana, entretanto pode-se ver ainda que a equipe conseguiu manter um ritmo de trabalho durante toda a sprint não ficando parada sequer um dia.
O velocity da equipe aumentou mais um pouco em relação a sprint passada, tendo como principal motivo as dívidas que foram satisfeitas durante a sprint.
Pode-se ver uma melhora no conhecimento de parte dos membros do grupo, principalmente em relação a linguagem de desenvolvimento do sistema (Python) e ao framework utilizado (Django). Isso evidência que a equipe tem uma maturidade melhor em relação ao desenvolvimento do sistema, e é mais um fator que auxilia no crescimento do burndown, aumentando a produtividade da equipe.
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 5, assim como as ações tomadas.
Dito isso, podemos ver abaixo a retrospectiva da sprint 5:
Com base nos pontos negativos e a melhorar, foram feitas ações, que serão ditas abaixo:
- Melhorar planejamento: Um dos pontos negativos é que o planejamento foi feito por Hangouts, o que pode ter acarretado em um pior planejamento por conta da incapacidade de uma ferramenta online ser tão eficaz quanto uma reunião cara a cara, com isso todas as próximas reuniões serão feitas presencialmente. O motivo de se fazer uma reunião pelo Hangouts, era para ser um teste piloto para ver se daria certo ou não.
- Buscar formas de motivar a equipe: Esse ponto não foi muito focado, por mais que seja uma coisa recorrente não acarreta não está influenciando a produtividade da equipe, logo pode-se ver que a desmotivação não é algo com a matéria e sim com a faculdade no geral.
- Redefinir escopo junto ao cliente: O escopo foi fechado com o cliente de uma maneira bem clara, entrando em um acordo do que será feito ou até o fim do projeto.
- Reclamações excessivas dificultam a conclusão das tarefas: Mais uma vez a equipe de GPP tem tentado explicar para os membros de MDS acerca das decisões, entretanto tem alguns membros que levam para o lado pessoal algumas decisões.
- Desmotivação: Assim como dito no item de Buscar formas de motivar a equipe vê-se que essa desmotivação é algo além do que a equipe de gerência possa fazer, e pode-se ver ainda que por mais que alguns membros estejam um pouco desmotivados o seus desempenhos continuam o mesmo.
- Cansaço: Conforme vai chegando o final do semestre esse sentimento de cansaço atinge a maior parte dos integrantes, o que estamos tentando deixar bem claro é o crescimento dentro do curso que os integrantes terão após a matéria, além de que é bom falar que logo logo irá acabar, pois já estamos chegando na reta final.
- Sobrecarga da equipe: Melhorar o planejamento serviu para atacar esse ponto negativo, pois distribuindo melhor os trabalhos não haverá esse sentimento de sobrecarga.
- Michel faltou a reunião sem justificativa: O membro abandonou a matéria, logo não há medidas para esse caso.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 6.
Ao final dessa sprint temos novamente uma agregação de valor maior ao cliente do que o planejado inicialmente no projeto. sso ocorre porque ao longo da execução do projeto novos requisitos surgiram e os mesmos foram implementados pela equipe.
A Variação do Prazo e o Índice de Desempenho de Prazo demonstram que estamos entregando mais histórias do que o planejado para a sprint isso ocorre por conta das dívidas da sprint passada.
Vale-se ressaltar que o valor agregado continua ultrapassando o valor planejado, ainda que ela tenha tido dívidas. Isso ocorre novamente por conta de se ter feito várias histórias de dívidas passadas.
Essa sprint teve um peso maior para os membros de MDS, pois foi acordado entre a equipe que a equipe de GPP não focaria muito na matéria durante essa sprint por conta de outras matérias da faculdade. Logo a sprint acabou sendo um teste para verificar se a equipe de MDS conseguia dar andamento no trabalho sem necessitar de interferência da equipe de GPP.
Conforme os resultados apresentados e visualização do trabalho feito durante a semana, pode-se perceber que a equipe de MDS conseguiu dar um andamento no trabalho, assim como manter um ritmo de trabalho bom aumentando a quantidade de pontos feitos, ainda que estivesse com alguns membros a menos (Alunos de GPP). Vale ressaltar uma das pessoas chaves para esse crescimento durante essa sprint que foi a Natália, que demonstrou um amadurecimento em relação a linguagem muito grande.
Por fim, podemos verificar tanto com os dados relatados assim como na visão do Scrum Master que a equipe conseguiu ter um bom ritmo de trabalho, e a mesma está qualificada para terminar o projeto com sucesso.
