Sprint 1 Revisão e Retrospectiva
1. Indicadores de Qualidade do Processo
As histórias planejadas para a sprint de devops foram entregues, entretanto houve uma história de integração do frontend com as ferramentas de análise estática que não foi entregue durante a sprint. Todas as demais histórias foram entregues e finalizadas o que demonstrou que o estudo inicial feito pela equipe apresentou resultados.
OBS Como houve a decisão de separar os repositórios do projeto em frontend e backend, o ZenHub ferramenta utilizada para gerar as métricas de qualidade do processo de desenvolvimento gera burndown por repositório. Para não haver retrabalho da equipe optou-se por deixar os burndowns separados por repositório.
Toda as histórias foram entregues dentro do prazo estipulado, os pontos começaram a ser queimados no meio para o fim da semana por conta de muitas das histórias demandarem um estudo inicial de como seriam feitas.
Os gráficos de commit mostram que a equipe de fato começou a implementar as histórias no meio da sprint devido ao estudo que foi necessário no começo da sprint, mas devido aos estudos realizados no começo da sprint quando o time de desenvolvimento começou a realizar a codificação as histórias foram quase todas fechadas rapidamente.
OBS Do mesmo modo que o burndown é separado por repositório o velocity também ficou separado por repositório devido a forma como o ZenHub coleta essa métrica.
Como houve apenas uma sprint o velocity ainda não consegue refletir de fato a quantidade de pontos que a equipe consegue entregar em uma sprint. Com o passar das sprints essa métrica mostrará quantitativamente a força de trabalho que a equipe de desenvolvimento tem.
O time de desenvolvimento analisou que algumas atividades ficaram subestimadas demandando mais tempo que o planejado no planning poker. As atividades que demandaram mais tempo que o esperado foram referente a configuração das ferramentas de análise estática, essa demora ocorreu pela decisão dos testes serem executados no Travis dentro do mesmo container utilizado para desenvolvimento. A equipe nunca tinha feito os testes serem executados dessa forma, portanto não tinha o conhecimento para fazer as configurações isso demandou um tempo de estudo.
Ocorreu a discussão de deixar documentado como foi o processo de implementação das técnicas e práticas de devops que foram adotadas para que em futuros projetos possam servir de base. Isso é algo que a equipe de desenvolvimento ainda está analisando devido ao fato de tomar certo tempo e nem sempre todas os projetos seguirem a mesma linha.
Os restultados desta sprint se mostraram satisfatórios, na retrospectiva quando foi apresentado ao Product Owner Interno o motivo da construção do projeto seguindo os princípios de devops o mesmo se mostrou muito satisfeito e entusiasmado. Foi algo que ele sempre priorizou é a qualidade do produto que será entregue pela equipe de desenvolvimento, então se fazia necessário aplicar todas as técnicas que foram elencadas para esta segunda sprint.