Sprint 4
Planejamento
1. Objetivos e Duração
Duração:
11/09/2018 a 17/09/2018
2. Sprint Backlog
3. Pontuação da Sprint
4. Papéis
5. Pareamento
Não houve pareamento nesta sprint.
6. Riscos da Sprint
Os riscos indentificados nesta sprint foram:
Resultado
1. Sprint Review
A maioria das tarefas separadas para esta sprint foram realizadas com sucesso.
A única tarefa que não foi terminada foi "Criar Mapa de Requisitos".
Tal tarefa não foi aceita como entregue pois faltaram detalhes referentes aos
requisitos de Gamificação do projeto.
2. Sprint Retrospective
| Pontos Positivo | Pontos Negativos | Soluções |
|---|---|---|
| Estudo de testes | Falta de tempo devido à provas | Procurar se mais proativo |
| Comunicação via issues | Muita coisa para estudar (extra projeto) | Melhorar a retrospectiva da sprint (esquecer dontpad) |
| Pró-atividade de alguns membros | Procrastinação | Fazer reiunião geral para resolução do backlog de projeto até a release 1 |
| Apresentação dos documentos no GitHub Pages | Dificuldade de definir backlog pra release 1 | Tentar equilibrar os tópicos de estudo para as próximas sprints |
| Sprints Documentadas no Pages | Mudanças nos horários das reuniões | Um membro "dar um toque" em outro para fazer as atividades |
3. Quadro de Conhecimento
4. Burndown
Obs: Este foi o primeiro burndown criado a partir da ferramenta zenhub. A pontuação da sprint não foi queimada da forma como o burndown foi apresentado. A distorção entre o burndown real e o entregue pelo ZenHub foi a má utilização da ferramenta. Para que a ferramenta funcione corretamente as issues devem ser fechadas assim que são terminadas e consideradas prontas e, neste caso, elas foram fechadas na sprint review.
5. Velocity
Como é possível observar a taxa velocity da equipe até o momento é de 17 pontos.
6. Gráfico de Commit
7. Análise do Scrum Master
A sprint praticamente ocorreu como planejada. Tal afirmação tem
como fundamento o fato de que a única tarefa que não foi
aceita na sprint review somente não foi aceita por falta de alguns poucos
detalhes. Já o maior problema da sprint referiu-se
à má utilização do zenhub fica para a próxima sprint, então, uma revisão da
utilização da ferramenta zenhub e, atrelado a isto,
uma coleta das datas da entrega das tarefas extra zenhub.
O risco referente a realização de provas que a equipe de MDS faria
durante a sprint pode ser considerado como
contido com sucesso pois nenhuma das histórias que eles deveriam produzir
tornou-se uma dívida téncnica. Da mesma forma o risco da utilização
do github pages pela equipe de MDS também foi contido com sucesso.
Mesmo com todos os dois riscos mapeados contidos um terceiro risco
(não mapeado) foi encontrado. Durante a sprint ocorreu uma má utilização
do git flow por um membro de MDS. Tal membro subiu os dados da documentação
direto na master. Para que este risco não ocorra mais
foi enviado a todos os membros da equipe (tanto MDS quanto EPS) um script que,
ao ser atrelado ao bashrc do sistema operacional, indica a
branch na qual o desenvolvedor está ao utilizar o terminal. Além disto foi
configurada uma regra para a branch master no repositório. Tal
regra bloqueia commits diretamente na master.
Por fim vale ressaltar que houveram alguns problemas nas coletas de
métricas de burndown desta sprint. Um destes problemas foi a má utilização
do ZenHub que ocasionou em um problema na geração automática do burndown. Como
foi relatado na legenda deste gráfico este problema ocorreu pois o burndown
gerado utiliza o momento em que as issues foram fechadas e não os pipelines
criados no quadro kanban e, no nosso caso, as issues foram fechadas somente no
sprint review. Para que tal problema não ocorra novamente as issues devem ser
fechadas assim que validadas por mais de um membro de EPS e, também, fica
a cargo do scrum master da equipe a coleta de tais datas paralelamente.