Resultados Sprint 5
Sprint que consolida a primeira versão funcional do software, alcançando, parcialmente, o planejado para a primeira release.
Fechamento da Sprint
Issue | Status | Pontos |
---|---|---|
US10 - Editar Envio de Uma Nota | Concluída | 5 |
US14 - Visualizar Uma Nota Detalhadamente | Concluída | 8 |
US19 - Fazer o upload de uma nota fiscal | Concluída | 3 |
US20 - Gerar Relatório de Notas Fiscais em Um Período Selecionado | Concluída | 13 |
Atualizar Readmes | Concluída | 1 |
Refatorar Documento de Visão | Concluída | 2 |
Corrigir Layouts da Wiki | Concluída | 2 |
Refatorar Documento de Arquitetura | Concluída | 3 |
Elaborar a Matriz de Avaliação de Valor | Concluída | 3 |
Pontuar Sprints Anteriores | Concluída | 8 |
Unir Back-end e Front-end | Concluída | 13 |
Organizar Resultados da Elicitação de Requisitos | Não Concluída | 5 |
US34 - Acessar Página Principal | Não Concluída | 5 |
Adicionar Deploy Contínuo | Não Concluída | 21 |
Pontos Planejados Concluídos: 58
Pontos de Dívida Concluídos: 3
Pontos Não Agregados: 31
Burndown
O burndown indica que as issues começaram a ser entregues no meio da sprint. Com o advento da Semana Universitária, mais pontos foram planejados, entretanto, nem todas as issues foram entregues, em virtude de dificuldades técnicas.
Velocity
Apesar de algumas das issues alocadas para a sprint não terem sido finalizadas, percebe-se melhora no velocity da equipe, evidenciando sua capacidade de entrega máxima até o momento.
Riscos
Não foram identificados riscos novos no decorrer da sprint.
Retrospectiva
A equipe continua exibindo poucos pontos negativos na retrospectiva, entretanto, um deles se conecta à um dos riscos mapeados. O ponto negativo "Muitas atividades para apenas uma issue (EPS)", traz à tona o ponto negativo de "requisitos com alto nível de complexidade", onde EPS não percebeu a possibilidade de diminuição da issue em issues menores, com menor carga.
Sprint Anterior
Poucos pontos negativos se mostraram na sprint anterior:
Ponto Negativo | Correção Adotada |
---|---|
Dailies por hangouts (horários e atrasos) |
Discussão sobre o melhor horário e ferramenta para realização de dailies.
|
Muitas atividades para apenas uma issue | Apresentar as issues planejadas à equipe no planejamento de sprint, e discutir a possibilidade de redução destas. |
Quadro de Conhecimento
Foram adicionadas as metodologias adotadas pela equipe: Scrum e Kanban.O objetivo é visualizar a evolução do conhecimento de MDS nos princípios ágeis.
Registros de Presença nas Dailies
Dailies de segunda e sexta-feira são feitas por hangouts, às 21h30 e 20h00, respectivamente. As dailies de terça-feira e quinta-feira, são realizadas às 15h50, presencialmente, mas por ocorrência da Semana Universitária, foram realizadas via hangouts, às 21h30.
Nome | Segunda Feira | Terça Feira | Quarta Feira | Quinta Feira | Sexta Feira |
---|---|---|---|---|---|
Bernardo | ✔ | ✔ | ✔ | ✔ | ✘ |
Clarissa | ✘ | ✔ | ✔ | ✔ | ✔ |
Esio | ✔ | ✔ | ✘ | ✔ | ✔ |
Felipe | ✔ | ✔ | ✔ | ✔ | ✔ |
Jacó | ✘ | ✘ | ✔ | ✔ | ✘ |
Lucas | ✔ | ✔ | ✘ | ✔ | ✔ |
Mariana | ✔ | ✔ | ✔ | ✔ | ✔ |
Pedro | ✔ | ✔ | ✔ | ✔ | ✔ |
Saleh | ✔ | ✔ | ✔ | ✘ | ✔ |
Youssef | ✔ | ✔ | ✘ | ✔ | ✔ |
Avaliação do Scrum Master
Sprint com a maior pontuação planejada até o momento. A ocorrência da Semana Universitária permitiu o aumento de pontos, dado que a equipe não teve aulas, e nem se matriculou em atividades extracurriculares.
Apesar da sprint atípica, é possível perceber que a capacidade de entrega da equipe cresce progressivamente. As pontuações das próximas sprints estarão restritas aos valores refletidos pelo velocity.
A equipe de desenvolvimento foi capaz de entregar as histórias planejadas, com o back-end testado. Ao final da sprint, EPS percebeu a falta de granularização em uma das issues que era responsável, o deploy contínuo, pois era possível fragmentá-la, evitando sobrecarga no DevOps, e por fim, não contrair uma dívida técnica tão alta.
O risco de requisitos com alto nível de complexidade se mostra novamente durante a sprint, dessa vez refletindo uma issue de responsabilidade de EPS, onde não foi percebida a possibilidade de granularização desta. A resposta ao risco vem na revisão das issues planejadas, não apenas nas histórias de usuário e técnicas, como também as atribuições de projeto endereçadas à equipe de EPS.
As dailies de segunda, quarta e sexta-feira, ponto constante de busca de melhoria, tanto em qualidade quanto horários, apresentou melhora significativa, com maior participação da equipe e também diminuição de atrasos. As dailies remotas da equipe têm um ponto forte, que se mostra cada vez mais: quando um membro expõe uma dificuldade, alguém da equipe se manifesta para ajudar, dando início a uma nova sessão remota, onde as dúvidas e/ou dificuldades serão sanadas, contribuindo para a redução dos riscos de falhas de comunicação e de dificuldade com tecnologias escolhidas.
O final da Sprint 5 mostra uma equipe cada vez mais unida e engajada, que começa as issues e expõe dúvidas cada vez mais brevemente, evidenciando a busca por produtividade máxima.