Sprint 1
Planejamento
1. Objetivos e Duração
Duração:
21/08/2018 a 27/08/2018
2. Sprint Backlog
3. Pontuação da Sprint
Obs: O projeto possui um documento de visão e um documento de arquitetura. Estes documentos são constantemente evoluídos e, por isso, não possuem nem pontuação nem sprint definida entretanto para a produção dos mesmos ser evidênciada no projeto tais documentos foram atribuídos a esta sprint.
4. Papéis
5. Pareamento
6. Riscos da Sprint
Os riscos indentificados nesta sprint foram:
Resultado
1. Sprint Review
O tema do projeto foi definido nesta sprint isso permitiu com que todas as
tarefas da sprint fossem concluídas.
2. Sprint Retrospective
| Pontos Positivo | Pontos Negativos | Soluções |
|---|---|---|
| Rapidez na conclusão dos documentos | Mudanças no projeto | Reformular a visão geral do projeto de acordo com os novos desafios |
| Criação das Issues no Repositório | Poucas pessoas comparecendo aos treinamentos | Reforumular horários para a efetuação dos treinamentos marcados e buscar ter mais compromisso com os mesmos. |
| Persistência dos pontos positivos da sprint passada | Baixa aderência às reuniões de sprint review, sprint retrospective e sprint planning. | Passar a tratar com mais seriedade os horários de sprint review, sprint retrospective e sprint planning. |
3. Quadro de Conhecimento
4. Burndown
Obs: Os valores de entrega deste burndown foram aproximados pois não houve datação das entregas na sprint 1.
5. Velocity
O velocity agora possui duas sprints como histórico alcançando uma taxa média de 13 pontos.
6. Gráfico de Commit
7. Análise do Scrum Master
No decorrer da sprint o grupo descobriu que faria um aplicativo que
ser um
dos serviço de um aplicativo maior. Este aplicativo maior será construído
juntamente
com outras 3 equipes de projeto. Tal notícia acarretou numa grande mudança na
visão
de projeto da equipe além de trazer novos riscos para a produção do próprio
como, por
exemplo, a integração de todos os quatro serviços em um único front end.
Outro ponto observado foi a adição dos treinamentos de django rest
e python no meio
da sprint. Esta decisão foi tomada pois com a notícia de que o projeto fará
parte
de um aplicativo feito por mais grupos houve a necessidade de haver uma
padronização
de ambientes de back-end da aplicação que agora serão em django rest.
Sobre o risco de decisão de tema no meio da sprint teve-se como
solução o prosseguimento de estudo/treinamento
sobre metodologia e ferramentas que vão ser utilizadas. Tal medida se mostrou
positiva pois a equipe continua
a aprender tais tecnologias. Sobre o risco de horários para os rituais foi
tomada a solução de analisar o quadro
de horário livre de cada um dos membros e procurar os horários que a totalidade
da equipe está livre. Tal medida
foi parcialmente positiva pois foi identificado que só seria possível a
realização de 3 daily meeting permanentes
(terça, quinta e sexta feira). Por fim o risco sobre elicitar mal os requisitos
foi sanado utilizando uma análise do
brainstorming de elicitação como também uma observação participativa dos
membros da equipe que fazem, também, parte do público
do projeto.
A equipe demonstra, de acordo com o velocity, poder produzir ainda
mais do que já está produzindo. Esta conclusão pode
ser tomada levando em consideração o crescimento na taxa do velocity partindo a
sprint 0 para a sprint 1. entretanto
deve ser levado em consideração, também, o burndown de pontos que mostra que a
equipe produz quase que na
linha ideal de entregas porém tal burndown não possuí um nível significante de
validade por ser um burndown aproximado de queima de pontos.
Logo, para a sprint seguinte é importante tentar aumentar os pontos para
entrega visando analisar a produtividade da equipe.