Skip to content
MatheusRich edited this page Jan 30, 2018 · 1 revision

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?
TS05 - Adapter para API
TS08 - Testes de Aceitação
TS09 - Validações no FrontEnd
US18 - Manter Feature ➕ / ➖
US20 - Manter EVM ➕ / ➖
TS04 - Testes Unitários ➕ / ➖
TS06 - Refatorar os componentes Releases e Sprints

1.1 O que foi feito?

  • US20 - Manter EVM (BackEnd)
  • TS05 - Adapter para API (Completo)
  • TS08 - Testes de Aceitação (Completo)
  • TS09 - Validações no FrontEnd (Completo)
  • US18 - Manter Feature (BackEnd)

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

  • US20 - Manter EVM(FrontEnd)

    • História possui uma alta complexidade;
    • Conhecimento dos requisitos foi tardio (devido à disponibilização pelo cliente apenas no meio da sprint);
  • TS06 - Refatorar os componentes Releases e Sprints

    • O tempo gasto para outras matérias comprometeu a realização da história;
  • US18 - Manter Feature (FrontEnd)

    • Dependência entre os arquivos aumentou a dificuldade de realizar os testes;
  • TS04 - Testes Unitários

    • Treinamento não aconteceu e membros não tiveram proatividade suficiente para buscar a informação por conta própria;

2. Retrospectiva

2.1. O que deu certo?

  • Os testes de aceitação foram implementados.

2.2. O que deu errado?

  • O fim do semestre dificultou a disponibilidade da equipe;
  • Testes unitários não foram desenvolvidos devido à falta de treinamentos e proatividade da equipe;
  • Membros mantiveram-se dispersos durante as reuniões;
  • O codclimate não coleta mais a métrica de GPA e por esse motivo, essa funcionalidade será retirada do sistema.

2.3. Como melhorar?

2.3.1. Must Have

  • Manter apenas um computador ligado nas reuniões de retrospectiva e planejamento de sprint;
  • Arrumar o webhook em produção.
  • Treinamento de teste unitário deve acontecer;
  • Fazer o próximo planejamento e revisão da Sprint utilizando o Falko.

2.3.2. Nice To Have

  • Os membros deveriam parear todos os dias.

3. Burndown Chart

Devido a trabalhos e atividades importantes de outras disciplinas a equipe não conseguiu se dedicar tanto no começo da sprint, e por esse motivo, a queima de pontos foi tardia. Além do mais, apesar de termos pego poucas histórias (apenas duas), nenhuma delas foi concluída totalmente, no entanto, algumas dívidas técnicas foram solucionadas.

4. Velocity

O velocity demonstra uma pequena queda no desempenho da equipe nesta última sprint, entretanto, continua no intervalo de 12. De maneira geral, foram concluídos um número bem menor de pontos ao final da sprint.

5. Relato do Scrum Master

A partir dessa Sprint notou-se que devido a o projeto estar perto de seu prazo, seria importante resolver mais histórias técnicas para melhorar a qualidade do nosso software, no lugar de desenvolver novas funcionalidades com baixa qualidade de código. Isso porque agregaria maior valor ao cliente e evitaria um maior número de refatorações posteriores. Nessa Sprint também a maioria dos estudantes estava com outras atividades importantes da faculdade, como por exemplo, trabalhos finais e por isso a equipe não conseguiu se dedicar de forma tão intensa ao projeto, demorando para queimar os pontos.

6. Métricas

6.1 Duplicação

Através da relação apresentada anteriormente, percebe-se que a duplicação de código que antes era persistente em alguns arquivos, chegando a 6, reduziu nessa sprint. No entanto, com o surgimento de novos trechos de código, a duplicação surgiu para esses outros arquivos.

6.2 Cobertura

A cobertura de código subiu novamente em 2%, demonstrando a constante preocupação dos desenvolvedores com a qualidade do produto desenvolvido, de maneira que mesmo os novos arquivos adicionados foram testados até o limite cobrado na disciplina, ainda assim, há muito o que melhorar.

6.3 Quadro de conhecimento

6.4.1 Antes da sprint 8

6.4.2 Depois da sprint 8

Conforme a comparação entre os dois quadros apresentados, percebe-se que o conhecimento da equipe não estagnou, entretanto, tem aumentado de uma maneira mais lenta. Isso se deve principalmente ao alto amadurecimento da equipe.

Falko

Cronograma Versão 3


Acesso à aplicação


Equipe

Release 02

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Sprint 9

Release 01

Gerenciamento do Projeto

Artefatos de Desenvolvimento

Encerramento

Clone this wiki locally