Sprint 1 Resultados

Sumário

1. Revisão

2. Retrospectiva

3. Burndown Chart

4. Velocity

5. Relato do Scrum Master

6. Métricas

---

1. Revisão

História	Foi concluída?
US01 - Pesquisar Projeto	✅
US03 - Conectar Conta ao Github	❌
US09 - Manter Release	➕ / ➖
US10 - Manter Sprint	➕ / ➖
US14 - Manter História	❌

1.1 O que foi feito?

• US10 (Backend)
• US09 (Backend)
• US01 (Completo)

1.2. O não foi feito e por que não foi feito?

• US03
  • Início de desenvolvimento tardio;
  • Existiram problemas com CORS;
• US14
  • Desenvolvimento tardio;
  • Problemas com ambiente de desenvolvimento;
• US10 (Front-End)
  • Desenvolvimento tardio;
  • Backend levou muito tempo para ser desenvolvido;
• US09 (Front-End)
  • Equipe inexperiente com rails API;
  • Histórias técnicas não concluídas, mas importantes;
  • Faltou tempo para que essa fosse concluída;

2. Retrospectiva

2.1. O que deu certo?

• Time cumpriu com os stand-ups;
• Pareamentos foram efetivos na troca de conhecimento entre os membros da equipe;

2.2. O que deu errado?

• Desnível grande de conhecimento entre o time;
• Dependência do time de MDS com relação à GPP;
• Alguns pareamentos não aconteceram;
• Problemas técnicos com internet dificultaram o uso de ferramentas importantes como hangouts;
• Desenvolvimento tardio
  • O fim de semana não foi bem aproveitado para o desenvolvimento;
• Um dos membros da equipe foi lesionado em atividades externas;

2.3. Como melhorar?

2.3.1. Must Have

• Formalizar os horários de pareamento;
• Adicionar uma reunião de desenvolvimento no sábado;
• Treinamentos de tecnologias;
• Melhorar lógica de alocação dos pares;
• Melhorar a atuação do Scrum Master;

2.3.2. Nice To Have

• Tentar parear presencialmente fora da faculdade

3. Burndown Chart

Como citado anteriormente, a inexperiência do time comprometeu o desenvolvimento das histórias. Isso vê-se refletido no _burndown_, onde a maior parte das histórias não foi concluída. Além disso, percebe-se que os pontos começaram a ser queimados tardiamente (4 dias depois do início da sprint).

Na sprint seguinte, deve-se fazer um esforço para que os pontos sejam não apenas queimados mais cedo, mas queimados por completo, não deixando dívidas.

4. Velocity

Devido à quantidade de histórias não concluídas, o velocity do time ficou bem abaixo do número de pontos planejados.

Na próxima sprint, a equipe deverá quitar as dívidas deixadas e cumprir um planejamento com um número menor de pontos, de forma equilibrada à produtividade observada.

5. Relato do Scrum Master

Nesta sprint muitas dívidas foram deixadas. As histórias, em sua maioria, foram apenas parcialmente completas. Isso se deu devido o desnivelamento da equipe em geral. A dependência da equipe de MDS em relação à equipe de GPP e a falta de conhecimento simultâneo, nos dois âmbitos da aplicação (back e front-end) acabaram atrasando o desenvolvimento. Além disso, o final de semana foi inutilizado para a produção de código.

A equipe havia decidido que cada história seria considerada de maneira completa (back-end e front-end). Sabíamos que isto geraria um overhead inicial, pois as histórias levariam muito tempo para serem concluídas, como foi possível observar nesta sprint. Entretanto, o grupo ainda acredita que seja a melhor abordagem, pois atua na disseminação do conhecimento da aplicação em sua totalidade.

Para a próxima sprint espera-se que os débitos sejam quitados, com o amadurecimento da equipe. Ademais, uma nova reunião no primeiro dia da sprint (sábado) será estabelecida, e os pareamentos serão alocados de forma a colaborar com estas atividades.

6. Métricas

6.1 Churn

6.2 Duplicação

Observa-se que os arquivos mais críticos a serem refatorados são os testes de User e Project. Deve-se fazer utilização dos setups para evitar a duplicação de código nessas áreas.

6.3 Cobertura

A cobertura de testes no BackEnd está num nível aceitável, em cerca de 82%. Porém ela deve ser aumentada para obedecer às exigências da disciplina (90% de cobertura).

6.4 Quadro de conhecimento

6.4.1 Antes da sprint 1

Este quadro de conhecimento representa a situação da equipe após os treinamentos iniciais e pouco tempo de início de desenvolvimento (representado pela primeira release), em que é possível ver que a equipe de maneira geral possuía um baixo domínio das tecnologias necessárias para o desenvolvimento da aplicação.

6.4.2 Depois da sprint 1