Pontuação de tasks e quebra das histórias em menores foram mudanças adotas para essa sprint. Existem riscos de não entrega de ambiente de produção e homologação até a
Release 1, bem como o protótipo de alta fidelidade e a identidade visual do produto.
Resultados
Resultado da Revisão da Sprint
Histórias entregues
Dívidas entregues
Pontos de dívidas entregues: 32
Todas as dívidas alocadas para essa sprint foram entregues.
Retrospectiva da Sprint
Pontos positivos
Ambiente está finalmente estabilizando;
Pareamentos Efetivos;
Membro Motivado
Pontos negativos
Membro Ausente;
Membros Tirando Dúvidas em Horários Indevidos;
Muitas issues complexas por sprint.
Outro membro se retirou da equipe, agora de MDS.
Possíveis melhorias
Pensar melhor nas histórias no momento de pontuar;
Mensagens de dúvidas no privado apenas até às 23:00.
Estruturação básica das classes de domínio da aplicação e do banco de dados. Criação de protótipo. Arquitetura de micro serviços. Definição do pipeline
Dados gerais
Data de início: 15/09/2018
Data de término: 21/09/2018
Pontos Planejados: 32
Pontos Adicionados: 13
Pontos totais: 45
Pareamentos
Os pareamentos foram distribuidos pensando na disponibilidade dos membros, já que muitos possuem atividades avaliativas durante essa sprint, tentou-se equilibrar
agrupando os que possuiam mais tempo para poder dedicar as histórias com aqueles que não poderão trabalhar com tamanho afinco.
O pareamento foi feito entre membros de MDS que estão responsáveis por implementar a história, e membros de EPS foram atribuídos a história para poderem testá-la.
Durante essa sprint foi definida a realização de uma stand up meeting na quarta as 15:50, utilizando
a sugestão de melhoria mapeada durante a retrospectiva da sprint 4. Também foram fatiadas as histórias em menores tamanhos, na tentativa de reduzir entregas feitas apenas no último dia da sprint.
Com a definição básica da arquitetura, os membros agora tem uma base para começar a desenvolver o produto
Foram escritas as primeiras linhas de código!
A documentação está acessível para todos os membros do time que estão alinhados sobre sua importância
Houveram feedbacks positivos em relação ao trabalho da equipe
Pontos negativos
Existem membros sobrecarregados, que são vistos como 'heróis'
A comunicação não foi constante, e dificuldades não foram comunicadas no meio da sprint
Membros foram alocados para muitas tarefas, tendo atividades de outras matérias
Receio de atraso em relação a outros grupos da matéria
Possíveis melhorias
Quebra das atividades em menores
Mais standup meetings
Medições obtidas dos indicadores e métricas
Riscos
Mais riscos foram identificados, porém houveram ações para tentar impedir a concretização destes. Houve a execução de um dojo para
iniciar a primeira história de código da equipe, que foi entregue ao final da sprint. Foram definidas as tecnologias que seriam utilizadas
dentro da arquitetura do projeto, diminuindo assim o risco de dificuldades no desenvolvimento e facilitando a configuração do ambiente. Tentou-se
fazer o planejamento observando os dados já existente sobre conhecimento e trabalho do time para que o planejamento não fosse ineficiente
Quadro de horas
Durante essa sprint os membros trabalharam por mais horas e também entregaram mais issues, não pode-se fazer uma interpretação em relação aos pontos entregues
pois foi a primeira sprint pontuada da equipe.
Velocity
Das histórias planejadas, apenas uma não foi entregue, e todas as dívidas foram entregues.
Com a definição da arquitetura, foram mapeados outros conhecimentos para o quadro de conhecimento da equipe.
Análise Geral
Embora tenha sido evidenciado que o trabalho não ficou dividido de forma uniforme entre os membros da equipe, foi entregue a maioria das histórias alocadas. Mais uma vez, foram deixadas para
entrega ao final da sprint, o que resultou em revisão tardia e não entrega de uma história, como o risco de não entrega de outras, como pode ser observado no burndown da sprint.
Faz-se necessário a quebra em histórias menores, para que haja possibilidade de entregas durante a semana e também a inclusão de uma reunião de stand up no meio da sprint, pois estas
estão sendo realizadas apenas nas terças e quintas. Observou-se, mais ao final da sprint, maior proatividade e independência do time de desenvolvimento.
Membros presentes na reunião de planejamento da Sprint
André Lucas
Rogério
Fabíola Malta
João Victor
Kaique Henrique
Matheus Vitor
Marcos Nery
Sannya Santana
Objetivo
Refinar a visão do produto e inicializar configurações de ambiente e entendimento da arquitetura. Reunião será realizada com o cliente dia 03/09/2018, no início da sprint, para
orientar os artefatos relacionados a visão, em paralelo, serão realizadas atividades de arquitetura e devops para assegurar o ambiente de desenvolvimento.
Dados gerais
Data de início: 01/09/2018
Data de término: 07/09/2018
Pontos Planejados: Não se aplica
Pontos Adicionados: Não se aplica
Pontos totais: Não se aplica
Conseguimos conversar com o cliente de forma a definir a visão do produto e fechar o escopo
Nada foi deixado para última hora (por MDS).
Terminamos o documento de visão
Comunicação do time para cumprir as tarefas mesmo com o feriado atrapalhando
Pontos negativos
Feriado
Membro do time viajando
Prova de outras matérias de EPS
Falta de produtividade/engajamento de EPS
Criação de issues durante a sprint e alocamento dela por membro do time
Muitas ferramentas de comunicação, time dividido entre elas
Galera faltando as dailies (EPS)
Melhorias
Acabar o grupo do telegram
Seguir a metodologia
Comprometer-se com as issues atribuídas
Medições obtidas dos indicadores e métricas
Quadro de Conhecimento
Quadro de Horas
Riscos
Em relação aos riscos mapeados para essa sprint, os que se concretizaram foram a baixa produtividade do grupo, e planejamento ineficiente,
resultando em dívidas. A visão de produto foi esclarecida com o cliente, delimitando de forma mais clara o escopo do projeto.
Houveram provas de outras matérias, diminuindo as horas dedicadas ao projeto.
Análise Geral
Nesta sprint, houve esclarecimentos fundamentais em relação a visão do produto, uma preocupação existente em membros da equipe. Porém, vários membros não se dedicaram
ao projeto, não participando dos rituais e nem entregando suas issues, o que comprometeu a produtividade do time.
A revisão da sprint foi realizada utilizando uma adaptação do mapa de empatia, observada na imagem a seguir:
Pontos positivos
Conseguimos configurar a atualização contínua do docusaurus!
Spam do github bot! Existem membros trabalhando constantemente no time
Alguns membros deixaram para realizar o trabalho apenas no final da sprint
Aprendizagem contínua
Motivação, membros estão sendo constantemente assegurados.
Pontos negativos
A visão do produto ainda não está concretizada, devido a dificuldades de comunicação com o cliente
O time de MDS ainda possui medo de realizar commits, mesmo de documentação
Spam do github bot! Como o time estava utilizando um grupo do telegram para comunicação e o bot estava nele,
algumas informações se perderam por conta do bot
Os critérios de aceitação de documento não estavam dispostos de forma direta, MDS não sabia a necessidade de revisão
antes de aceitar o Pull Request.
Sensação de atraso constante e instabilidade
Possíveis melhorias
Realização de um encontro do time, para entrosamento
Troca de ferramenta do telegram para o slack
Não commitar na master!
Não aceitar o próprio pull request
Realizar trabalho constante durante a sprint
Seguir a política de branchs
Saber filtrar críticas externas
Análise Geral
Apesar de muitas issues não entregues, os artefatos relacionados com a visão do produto já esperava-se esse resultado, pois eles foram alocados para elicitar dúvidas
que poderiam ser levadas para o cliente e ter melhor base em relação aos requisitos do projeto. Issues foram deixadas para o final da sprint, o que
concretizou o risco da não entrega. O time ainda não está seguindo o processo de forma consistente.
Apesar de dificuldades de comunicação entre cliente e time, a comunicação interna do time está fluindo,
possibilitando todos estarem alinhados sobre o andamento do projeto;
O time está se esforçando para conhecer as tecnologias e processos que estão sendo utilizados nas disciplinas
Pontos negativos
Local e horário da reunião com o cliente, resultando em faltas em aulas de membros;
Primeiro contato com cliente confuso em relação a que papel ele desempenhará no decorrer do projeto, bem como
o produto que não sabe-se ao certo se seria resultado de uma evolução de software ou um novo produto;
Aviso tardio de uso de github pages para documentação, resultado em retrabalho
Reuniões aos sábados
Possíveis melhorias
Pontualidade de alguns membros nas reuniões;
Elucidar o papel do cliente, melhor delimitar o projeto e manter transparência na comunicação com ele;
Mudar a data de fim de sprint para sábado e início da sprint para segunda
Definição de conceito de entregue para documentos, não apenas para código
Análise Geral
Embora ainda não plenamente estabelecido o processo do time, nessa sprint foi percebido
resultados mais concretos do time, e foram possíveis treinos e estudos. Ainda não foram entregues
alguns artefatos, por confusão na definição de entregue em termos de documentação, que não foi um acordo
do time ainda. Houve comunicação constante entre os membros de eps e mds, que não hesitaram em tirar dúvidas
entre si.
Durante essa sprint, que ocorreu na primeira semana de aula,o time foi formado e teve seu primeiro contato, bem como os primeiros treinos em: engenharia de requisitos, métodos ágeis e fluxo de trabalho usando Github.
O processo não estava bem definido e também não havia definição do tema do projeto, então as reuniões não foram executadas. Ao final da sprint, foi definido o tema do trabalho.
Para melhoria das próximas sprints, deve-se realizar mais treinamentos para capacitação do time e definir o processo e comunicação do time, para que haja alinhamento.
