Resultados Sprint 6
Sprint que contempla a ocorrência da primeira release. Revela o alcance da produtividade máxima da equipe, e consolida a primeira versão funcional do software.
Fechamento da Sprint
| Issue | Status | Pontos |
|---|---|---|
| Criar a Release do Projeto | Concluída | 0 |
| Complementar Documento de Arquitetura | Concluída | 1 |
| Evoluir US10 | Concluída | 2 |
| Evoluir Identidade Visual | Concluída | 3 |
| US34 - Acessar Pagina Principal | Concluída | 5 |
| Organizar Resultados da Elicitação de Requisitos | Concluída | 5 |
| Adicionar Deploy Contínuo | Concluída | 21 |
| Evoluir US 20 | Não Concluída | 1 |
| Evoluir TAP | Não Concluída | 2 |
| Criar o EVM | Não Concluída | 8 |
| US33 - Gerar Relatório por Período Definido | Não Concluída | 13 |
Pontos Planejados Concluídos: 6
Pontos de Dívida Concluídos: 31
Pontos Não Agregados: 24
Burndown
Sprint com poucos pontos planejados, em razão da ocorrência de dívidas técnicas oriundas da sprint anterior. Também poucos pontos planejados para refino dos artefatos e correção de algumas das histórias de usuário concretizadas até o momento, para apresentação na release.
A release ocorreria na quinta-feira (04/10), portanto, esperava-se que as issues fossem entregues um dia antes. É possível perceber a entrega antecipada, dado que a equipe começou o trabalho logo após o planejamento da sprint.
Velocity
O velocity se mantém estável, visto que poucos pontos foram planejados. A pontuação, em sua maioria, contemplava dívidas técnicas, portanto, esperava-se que a pontuação concluída fosse acima da pontuação planejada.
Riscos
Não foram identificados riscos novos no decorrer da sprint.
Um dos riscos mapeados se mostrou, dado que um membro da equipe de desenvolvimento trancou a disciplina.
Retrospectiva
A equipe continua apresentando poucos pontos negativos na retrospectiva. Os pontos negativos expostos nesta sprint são inferiores aos apontados na anterior, entretanto são diferentes, dado o contexto atípico no qual a sprint ocorreu (release I).
Sprint Anterior
Com relação aos pontos negativos apresentados na retrospectiva anterior, algumas medidas foram tomadas para que não se mostrassem novamente, são eles:
| Ponto Negativo | Correção Adotada |
|---|---|
| Muitas atividades para apenas uma issue (EPS) | Discutir a possibilidade de redução das issues planejadas relacionadas ao projeto, que são responsabilidade de EPS. |
Quadro de Conhecimento
A definição de pronto das histórias de usuário e técnicas sofre mudança para a release II, com a obrigatoriedade de testes sendo construídos, a coluna "testes" deu origem a duas novas: "testes Flask" e "testes React", facilitando o rastreio mais apurado das habilidades da equipe.
Registros de Presença nas Dailies
- Dailies de segunda e sexta feira são realizadas por hangouts, às 21h30 e 20h, respectivamente.
- Dailies de quarta-feira são realizadas por telegram, às 12h.
- Dailies de terça e quinta feira são realizadas presencialmente, às 15h50.
| Nome | Segunda Feira | Terça Feira | Quarta Feira | Quinta Feira | Sexta Feira |
|---|---|---|---|---|---|
| Bernardo | ✔ | ✔ | ✘ | Release I | ✔ |
| Clarissa | ✔ | ✔ | ✔ | Release I | ✔ |
| Esio | ✔ | ✔ | ✔ | Release I | ✔ |
| Felipe | ✔ | ✔ | ✘ | Release I | ✔ |
| Lucas | ✔ | ✔ | ✔ | Release I | ✔ |
| Mariana | ✔ | ✔ | ✔ | Release I | ✔ |
| Pedro | ✔ | ✔ | ✔ | Release I | ✔ |
| Saleh | ✔ | ✔ | ✔ | Release I | ✔ |
| Youssef | ✔ | ✔ | ✔ | Release I | ✔ |
Avaliação do Scrum Master
Sprint que representa o alcance da produtividade máxima da equipe. Foi marcada pelo cansaço evidente, inclusive apontado na retrospectiva, como "planejamento inferior" e "estresse pré R1".
Apesar do contexto em que a sprint aconteceu, na semana da primeira release, é possível perceber que a capacidade de entrega da equipe se mantém, mesmo com o planejamento inferior ao usual, com carga alta e desbalanceada. Também é perceptível a incidência de dívidas técnicas acima do normal.
Durante a busca pelo ponto de produtividade ótima, após certo número de sprints com pontuações cada vez maiores, é natural não atingir o planejado. Ao perceber o ponto de falha, as próximas sprints estarão restritas aos valores reproduzidos pelo velocity.
O velocity atual corrobora o atingimento da produtividade máxima. O número de pontos ideal para as próximas sprints se torna cada vez mais evidente, dado que um aumento gradual na pontuação, já alta, possivelmente podem causar cansaço, estresse e consequentemente desmotivação na equipe.
Os riscos de maior incidência nas últimas sprints, de requisitos com alto nível de complexidade, e de dificuldade com tecnologias adotadas, não se mostraram durante a sprint. A equipe de desenvolvimento se mostrou madura e capaz de finalizar as histórias dirigidas à eles, com a incidência de uma dívida, que, por conta do planejamento falho, não foi finalizada a tempo.
Visando recuperação da equipe, a sprint 7 foi planejada de modo a quitar as dívidas técnicas, com baixo número de histórias novas planejadas, evitando sobrecarga, tanto em MDS como em EPS.
Apesar da sprint inferior ao usual, a equipe foi capaz de entregar parte do planejado, e constatar sua produtividade máxima. Também ficou evidente a harmonia e esforço do grupo, resultando numa apresentação bem sucedida, transparecendo o empenho e profissionalismo da equipe a fim de entregar um produto de qualidade.