1. Resultados da Sprint

ID	História	Status
EP01FE01US01	Realizar/Confirmar alocação	Não Concluído
EP01FE01US02	Visualizar alocação	Não Concluído
EP01FE02US11	Alterar Turma	Não Concluído
FE06TS04	Refatorar Folha de Estilo	Concluído

Total de pontos concluídos: 13

2. Indicadores do processo

2.1. Análise do Scrum Master

Tendo em vista as sprints anteriores e analisando a retrospectiva, foi proposto algumas mudanças. Não se pode tirar uma conclusão definitiva sobre as mudanças propostas, mas com a retrospectiva desta sprint e conversando com o time, o feedback que pode-se tirar é que as mudanças agregaram para o desenvolvimento. O time teve uma presença maior do scrum master durante o desenvolvimento da sprint, onde haviam nos daily meeting as cobranças e após o daily meeting a conversa para solução de problemas enfrentados. O time com isso sentiu uma melhora na produtividade, mesmo que poucas histórias tenham sido entregues.

Nesta sprint ocorreu um problema com relação ao escopo do projeto, onde, em um dos standups foi levantado uma dúvida para a Product Owner e ao esta contactar os stakeholders, foi necessário parar todos o desenvolvimento, pois após o contato foi notado uma falha no entendimento do produto. Houve então na sexta-feira uma reunião com os stakeholders (coordenadora do curso de design, membro da prefeitura e membro do CPD), a Product Owner o Scrum Master e um membro do time que na sprint passada foste o Product Owner. Na sprint review foi repassado todas as alterações que foram conversadas com os stakeholders.

Ao fim da sprint o time chegou a conclusão que os pontos das histórias não refletiam o esforço real. Foi proposto para o planejamento da próxima sprint a repontuação do backlog do produto.

Durante a sprint, foi necessário desenvolver, revisar e atualizar varios artefatos na wiki, dentre eles:

• Planejamento da Release
• Metodologia
• Backlog do Produto
• Roadmap
• EVM (Earned Value Management)
• Modelo de Planejamento de Sprint
• Modelo de Resultados da Sprint.

Pode-se notar que até então o time esteve defasado em relação a estes artefatos, sendo por falta deles existirem ou estarem desatualizados.

2.2. Analise do Product Owner

Do ponto de vista colaborativo, esta sprint caracterizou-se por maior organização e comunicação entre os membros da equipe, quando comparada as sprints passadas. A partir da modelagem dos processos notou-se da equipe de desenvolvimento maior preocupação em alinhar a visão do projeto com o Product Owner, o que refletiu em um fluxo de desenvolvimento e validação mais rápido do protótipo, antes da implementação da user storie em si.

Nesta sprint foi almejado implementar a história de realizar alocação, a qual se tornou um gargalo no meio da sprint diante a existência de diferentes visões sobre como ocorria e como deveria ser implementado o processo de alocação de salas no sistema. Mediante a esta limitação sobre o processo a ser implementado, não foi possível avançar sobre as funcionalidades desta sprint e nem trazer novas funcionalidades, uma vez que a visão sobre as regras de funcionamento do sistema não estavam alinhadas entre cliente e a equipe.

Diante desta situação, notou-se a dificuldade de trabalhar com o Product Owner rotativo dentro do projeto. Primeiro, por não haver uma constância no fluxo de informações trocados entre o próprio cliente e o Porduct Owner, somado ao fato do cliente também não possuir a visão completa sobre todo o processo de alocação, trazendo responsáveis de outras áreas para tentar suprir essa dificuldade. De forma que, o Product Owner rotativo perde a visão global do problema por acabar não tendo contato com todos os envolvidos no processo de alocação. Outro ponto negativo nesta rotatividade esta relacionado ao fato das reuniões com a cliente ocorrerem nas sexta-feira, um dia antes do fechamento da sprint, ou seja, o Product Owner que iniciou da sprint, somente irá ter contato de fato com o cliente no final da sprint, de forma que a adaptação do Product Owner a visão de fato do cliente se dá somente quando o mesmo já está chegando ao fim do seu período de representação.

Dado estas difilcudades enfrentadas, a equipe reuniu-se com o cliente, visando esclarecer passo a passo o processo de alocação e optou por manter o Product Owner e Scrum Master na sprint seguinte, visando aproveitar o processo de adpatação e compreensão sobre o sistema sofrido por ambos. Tendo a finalidade de passar a visão geral sobre o processo de alocação obtida para todos os membros, antes de realizar uma quebra de novo na troca de papéis.

2.3. Burndown da sprint

Clique aqui para ver maior

2.4. Velocity da Sprint

Nessa Sprint foram concluídos apenas 13 pontos. O velocity do time pode ser visto no gráfico abaixo.

Clique aqui para ver maior

2.5. Quadro de Conhecimento

Clique aqui para visualizar maior

3. Retrospectiva

3.1. Pontos Positivos:

• Maior Comprometimento do time
• Melhor Desempenho
• Aumento na Produtividade
• Pareamento
• Daily Meeting mais organizado
• Organização
• Maior comunicação com o Product Owner

3.2. Pontos Negativos:

• Escopo instável
• Mudanças na regra de negócio
• Pontualidade
• Aumento do escopo
• Product Owner rotativo

3.3. Melhorias:

Não houve sugestões

4. Métricas

4.1 Cobertura de Testes

A cobertura manteve-se a mesma da sprint passada, isso decorre que apenas a história técnica de refatoração de folha de estilo foi concluída, a qual não acarretava em nenhuma mudança nos testes.

4.2 Complexidade Ciclomática (Flog) e Duplicações de Código (Flay)

Arquivo	Flog	Flay
users_controller.rb	13.8	32
parsers_controller.rb	4.6	0
application_controller.rb	0	0
sessions_controller.rb	8.5	0
department_assistants_controller.rb	0	0
coordinators_controller.rb	0	0
administrative_assistants_controller.rb	6.3	0
courses_controller.rb	0	0
rooms_controller.rb	4	0
school_rooms_controller.rb	3.3	0
sessions_helper.rb	5.4	0
department_assistant_helper.rb	0	0
application_helper.rb	7	0
coordinator_helper.rb	0	0
user_helper.rb	0	0
administrative_assistant_helper	0	0
parsers_helper.rb	0	0
courses_helper.rb	17	36
school_rooms_helper.rb	0	0
discipline.rb	0	0
course.rb	0	0
administrative_assistant.rb	0	0
user.rb	0	0
parser.rb	11.6	0
department.rb	0	0
department_assistant.rb	0	0
room.rb	0	0
coordinator.rb	0	0
building.rb	4	0
school_room.rb	0	0
application_record.rb	0	0

Nessa sprint a complexidade diminiu um pouco em alguns arquivos, isso se da pelo fato que ao adequar o projeto a folha de estilo, algumas smells são retiradas.

4.3 Turbulência (Churn x Complexidade)

De acordo com os apomtamentos do gráfico, ainda existem problemas, porém esses problemas são irrelevantes para o projeto, já que a maioria ocorre em arquivos de testes, onde a uma complexidade mínima não e exigida.

4.4 Checkstyles

Após a conclusão da história técnica de refatoração da folha de estilo, não há mais ofensas detectadas no projeto em relação a folha de estilo.

4.5 Falhas de Segurança

A segurança do projeto continua a mesma desde a primeira *release

4.6 Smells

Houve uma pequena diminuição no numero de smells, isso decore pelo fato da conclusão da história técnica de refatoração de folha de estilo.