Resultados da Sprint 2
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 1
- 1.8 Retrospectiva
2. Indicadores de Qualidade do Código
A versão da release da sprint pode ser vista em: versão v0.4.0
Nesta sprint não foram concluídas todas as histórias planejadas. Nesta sprint foram planejadas histórias para ajuste de funcionalidades existentes e o início da implementação de uma funcionalidade considerada fundamental para o andamento do projeto, a prescrição de um receituário. Houveram muitas dificuldades principalmente em relação as tecnologias necessárias para a realização do mesmo.
Nesta sprint a agenda de pareamento foi realizada novamente. Apesar da não conclusão de todas as histórias ela se mostrou útil novamente, pois auxiliou as duplas na organização de seu horários e assim auxiliando na realização do trabalho. Vale ressaltar que todos os horários não foram cumpridos de forma rigorosa, porém caso não fosse possível realizar o pareamento no horário inicialmente planejado, um novo horário era marcado e a equipe informada a cerca da mudança.
Como nesta sprint duas histórias planejadas não foram entregues, o burndown foi completamente comprometido. Porém, como ocorreu na sprint anterior, o burndown não representa o real desenvolvimento das funcionalidades durante a sprint pois o burndown só possui um progresso quando a história de usuário é entregue por completo. O burndown também não leva em consideração o tempo necessário para a análise do código antes da entrega da funcionalidade.
Porém como se pode notar no burndown acima, ao fim da sprint não foram completados todos os pontos planejados, ficando um débito de 18 pontos.
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 a parte do front-end do projeto. Isso é importante para a continuação do projeto, pois mostra que os membros estão se tornando mais confiantes em relação ao projeto como todo.
Seguir a agenda de pareamento: Nessa sprint a agenda de pareamento foi seguida de forma mais assídua pelos membros, possibilitando que os pareamentos ocorressem.
Mais confiança nas decisões: Como citado anteriormente, alguns membros de MDS conseguiram alcançar uma maior independência, tomando assim suas próprias decisões para a realização da implementação do projeto. Essa confiança nas decisões também trouxeram aos membros uma responsabilidade, aceitando mais os erros que cometeram.
Melhorar comunicação entre os membros com o cliente: Passaram a ser realizadas reuniões semanais com o cliente. Esta reunião sempre esta acontecendo no período noturno a cada terça feira. Nessa reunião estão presentes os membros de GPP e alguns membros de MDS que se tornam representantes de MDS.
Seguir as políticas do repositório: Nesta sprint tivemos menos problemas com o desrespeito as políticas previamente definidas, pois os membros agora as seguem respeitando os padrões definidos.
As métricas de qualidade de código da sprint estão especificadas e analisadas na página Métricas da sprint 2.
Ao final dessa sprint não estamos com o projeto tranquilo em relação aos indicadores da EVM. 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 do projeto,ou seja, estamos com a execução do projeto atrasada em relação ao que foi planejado para a release.
Durante a sprint 2 o time mostrou uma evolução, principalmente técnica, em relação a sprint 1. Isso fez com que ajustes necessários para a continuação do projeto fossem realizados e novas funcionalidades integradas ao produto.
Entre os principais pontos positivos dessa sprint temos uma certa independência adquirida por alguns membros de MDS, conseguindo ter mais confiança em suas ações e precisando menos do apoio dos membros de GPP. Porém entre os pontos negativos principais do projeto está o conflito de horário, o que impossibilita que algumas atividades do SCRUM sejam realizadas de forma correta, como a atividade do daily.
