Sprint 10

Planejamento

1. Objetivos e Duração

  • Reintegração dos serviços
  • Reestablização dos servidores de backend
  • Aprendizado de testes de react
  • Criação do ROI

    • Duração:
    23/10/2018 a 29/10/2018

    2. Sprint Backlog

    Issues Pontuação
    Fazer refatoração do código buscando solucionar problemas de integração 2
    Reestabelecer o deploy dos microserviços 5
    Restaurar servidor rancher no azure 3
    US16 - Fazer transição do ambiente front end dentro da organização CarDefense (fork do frontend) 3
    Modificar template da issues 1
    Estudar Testes Unitários [REACT] 2
    Subir servidor rancher na gcloud 5
    Fazer ROI do projeto 3
    Criar relatório sprint 10 2

    3. Pontuação da Sprint

  • Planejados: 26 pontos
  • Dívida Técnica da sprint anterior: 0 pontos
  • Executados: 23 pontos

    • 3.1. Sistema de pontuação Release 2
    Tipo de Tarefa Extensão Pontos Equivalentes
    Pequenas alterações de código/front - estilização CSS PP 1
    CRUD, bugfix em CRUD, documentação pequena, relatório de sprint P 2
    Refatoração de código, nova função de back, nova função de front, documentação extensa M 3
    Nova feature (back/front), alteração de arquitetura, alteração de DevOps G 5
    Bugfix complexo, geração de relatório complexo GG 8

    4. Papéis


  • Engenheiro de Produto: Stéfane Souza
  • Scrum Master: Paulo Vitor auxiliado por Lucas S. Souza
  • DevOps: Taynara Carvalho
  • Arquiteto: Mateus Vieira
  • Desenvolvedores: João Gabriel Rossi, João Gabriel Antunes, Ivan Diniz, João Matheus, Lieverton Santos

    • 5. Pareamento

  • João Matheus e Ivan
  • João Gabriel Antunes e Gabriel Rossi
  • Paulo Rocha e Lieverton

    • 6. Riscos da Sprint

    Os riscos indentificados nesta sprint foram:

  • Scrum Master inexperiente
  • Prova para alguns membros de EPS

    • Resultado

    1. Sprint Review


    Mesmo tendo um Scrum Master inexperiente na equipe obtivemos um resultado rasoável. A maioria das histórias foram entregues sendo que a única não entregue foi a referente à criação do ROI do projeto. Tal issue não foi entregue pois o responsável por ela obteve alguns problemas na elaboração do mesmo, logo, a finalização do documento ficou para a sprint seguinte.

    2. Sprint Retrospective

    Pontos Positivo Pontos Negativos Soluções
    Boa refatoração do App Grande mudança do ambiente no meio da sprint Ao terminar uma issue fechar no zenhub (para influenciar no zenhub)
    Deploy do Servidor Azure derrubou o servidor rancher com os microsserviços Tentar fazer com que o app se torne um pouco mais estável
    Facilitação de uma melhor gerência do app devido a separação do Integra Má integraçao do Expo ao Facebook Antes de propor uma história verificar se a mésma é viável para a sprint
    - Problemas encontrados fizeram com que os testes de usabilidade não ocorressem -

    3. Quadro de Conhecimento

    Quadro de Conhecimento Sprint 10

    Pode-se verificar que o conhecimento em testes unitários foi melhorado e possivelmente tal fator ocorreu pois os membros da equipe de desenvolvimento estudaram tal tópico na sprint. Uma preocupação ainda são os testes de aceitação do front.

    4. Burndown

    Burndown Sprint 10

    É possível verificar no burndown que ouveram entregas durante a sprint entretanto grande parte foi terminada no último dia (ao menos a issue foi fechada no último dia da sprint). Obs: O burndown apresentado mostra que todas as issues foram fechadas até o ultimo dia entretanto é importante ressaltar que uma issue (referente ao ROI) não foi entregue. O burndown apresenta este resultado pois quando foi coletado a dívida técnica já havia sido entregue

    5. Velocity

    Velocity Sprint 10

    Verifica-se que a média de entregas da equipe continua em 25 pontos. Após 3 sprint seguidas com tal valor médio já é possível definir que o valor mais próximo do ideal para a equipe é de 25 pontos por sprint.

    6. Gráfico de Commit

    Nesta sprint houveram sim vários commits entretanto houve uma falha na coleta dos gráficos logo eles não poderam ser apresentados neste relatório. Esta falha ocorreu pois houveram alguns commits das issues (que seguiram todo o gitflow e chegaram nas branchs masters) da sprint 11. É importante que o scrum master em exercício na sprint realize a coleta dos gráficos de commits e de qualquer outra métrica assim que a sprint terminar.

    7. Burndown de Riscos

    Burndown Riscos Sprint 10

    Para melhor visualização CLIQUE AQUI
    Pontuação: A escala do score de riscos vai de 0 (risco nulo) a 30 (risco extremamente alto)
    Houve a adição de novos riscos nesta sprint. Os riscos antigos foram parcialmente mitigados.

    8. Análise do Scrum Master



      A sprint foi totalmente entregue. Tal fato demonstra que as decisões sobre a quantidade de pontos por sprint, divisão das issues, e distribuição das tarefas foram muito benéficas para a execução do projeto. Fazendo com que a equipe comece a ter um novo valor de velocity para se guiar.

      Mesmo mitigando os riscos de membros faltantes um único membro continua muito distante do projeto. É extremamente necessário que se converse com ele pois a equipe necessita do esforço dele como também ele necessita da equipe para conseguir a aprovação na matéria. Caso fique muito complicado de se resolver tal risco é importante que a professora seja procurada.

      Está se mostrando como boa solução o fato de formar pareamentos onde membros que conhecem mais sobre front-end são pareados com membros que conhecem mais sobre back-end. Espera-se que logo ambos os membros (de cada dupla de pareamento) possuam um nivelamento no conhecimento de back e front ends.

      O risco referente a criação do APK continua altissimo e nenhuma decisão tomada até o momento fez com que tal risco seja mitigado. Logo, visando o gerenciamento dos riscos da equipe CarDefense é importante que seja solicitado a professora uma separação do nosso app do Integra. Assim poderemos seguir com nossa aplicação única e não teríamos que esperar as outras equipes para tomarmos decisões, como por exemplo, um merge para a criação do APK.

      Pode-se concluir que o trabalho continua sendo executado sem problemas graves. Entretanto deve-se acontecer uma reunião com a professora para decidirmos se o CarDefense continua dentro do Integra ou não. No mais é imporante que o scrum master continue procurando os membros faltantes e procure sempre um plano B visando a mitigação dos riscos.