Resultados Sprint 0
1. Indicadores de Qualidade do Processo
2. Indicadores de Qualidade do Código
Pontos Concluídos: 34
A fim de conseguir determinar um _velocity_ acabou se adicionando ao _backlog_ da _sprint_ uma quantidade superior do que o time consegue desenvolver. Isso foi perceptível nos resultados ao se observer que nem todas as histórias foram entregues. A história que não foi entregue foi justamente uma que o time não conseguiu determinar e pontuar da maneira correta, devido a falta de um conhecimento técnico mais apurado. Foi pensado que seria implementado de uma maneira, mas no decorrer da _sprint_ foi visto que não seria possível, logo teve que ser buscada outra alternativa, impossibilitando o término da **US03**. Mas de qualquer maneira, uma grande parte dela foi executada nessa _sprint_. Com relação as outras histórias, não se teve grandes problemas e todas foram entregues.
A principal dificuldade enfrentada pelo time foi incorporar a nova metodologia de desenvolvimento, e isso é visto no _burndown_, já que todas as histórias foram entregues no último dia da _sprint_. O time ainda não conseguiu absorver os valores de continuamente ir desenvolvendo e principalmente a importância dos testes, até mesmo pela dificuldade técnica presente.
Nota-se que o conhecimento do time é algo bem desnivelado e a dificuldade se concentra no banco de dados e nos testes. Mas de certa forma já se teve uma melhora para o que foi apresentado no planejamento da _release_, em que devido ao modo que foi conduzido a primeira parte da _release_ algumas pessoas acabaram não evoluindo como se desejou-se. De qualquer forma, acredita-se que com o pareamento orientado ao quadro de conhecimento, essas dificuldades sejam sanadas.
A maior parte das histórias eram técnicas e relacionadas às dividas técnicas da primeira _release_. Apenas três histórias envolviam a adição de funcionalidades no aplicativo. Uma destas não foi completamente implementada e, portanto, não foi entregue. Contudo, as duas implementadas envolvem a leitura do QR Code e a associação dele com um elemento. Essas histórias são essenciais ao nosso aplicativo e são a base para muitas histórias a serem implementadas em _sprints_ futuras.
O aplicativo não evoluiu tanto em funcionalidades como evoluiu em qualidade de código. Muitas das funcionalidades já implementadas possuem problemas devido à inexperiência com _Android_. Contudo, a funcionalidade crítica de leitura de _QR Code_ foi feita corretamente e com aprovação do cliente. A expectativa atual é de que, mesmo com o atraso de uma história, todas as histórias - técnicas ou de usuário - serão entregues ao final da segunda _release_.
Ao se comparar as métricas dessa _sprint_ em que se dedicou-se para a refatoração de algumas partes do código é possível perceber algumas melhoras, mas em si alguns indicadores ainda continuam alarmantes, como a complexidade ciclomática (acc) e o número de métodos (nom) na model. Algumas hipotéses que ainda não foram totalmente constatadas, mas que foram levantadas principalmente nessa _sprint_ é que essas classes são a base da aplicação e por isso acabam sendo utilizadas mais vezes e que a maneira que foi concebida essas classes impossibilitam grandes mudanças. Entretanto, a fim de entender melhor foram constatadas as classes de _Element_ e _Explorer_. Notou-se que apesar de terem métricas altas, são classes que pelo contexto necessitam de um grande número de métodos de validação e de suporte para outras classes. As métricas no pacote da _view_ foram as que mais diminuiram e permaneceram estáveis desde a primeira _release_. Tal fato pode ser ocasionado por não ter se adicionado grandes funcionalidades nessa _sprint_.
Infelizmente essa _sprint_ pecou um pouco em relação aos custos. Tal déficit no valor agregado em relação ao acumulado e ao real foi ocasionado pela história de usuário não entregue. E isso afetou diretamente os índices de variação e os índices de desempenho, deixando ambos abaixo do que era esperado.