1. Resultados da Sprint

ID	História	Status
EP01FE01US01	Realizar alocação	Não Concluído
EP01FE01US02	Visualizar alocação	Não Concluído
EP01FE04US31	Manter Categoria	Concluído
EP01FE02US12	Excluir turma	Não Concluído
EP01FE04US19	Excluir sala	Concluído
EP01FE01US27	Registrar Período de Alocação	Concluído
EP01FE04TS10	Refatorar sala	Concluído
EP01FE02TS09	Refatorar turma	Concluído

Total de pontos concluídos: 18

2. Histórias Adicionadas

Algumas histórias foram adicionadas durante a Sprint. No caso da EP01FE01US27, ela surgiu na última reunião com o cliente e na nova regra de negócio ela se tornou pré requisito da história Realizar Alocação. Por ser uma história simples, foi dada aos mesmos responśaveis da EP01FE01US01. Ela foi adicionada 15/05/2017. No caso das EP01FE04TS10 e EP01FE02TS09, elas foram adicionadas, pois os responsáveis da história EP01FE04US31 pediram para fazê-la junto com sua história. Elas foram adicionadas no dia 16/05/2017.

2.1. EP01FE01US27 - Registrar Período de Alocação (3pt)

2.1.1. User Story

Eu como PRC desejo cadastrar os períodos nos quais o sistema estará liberado para alocação com a finalidade de controlar o processo de alocação no sistema.

2.1.2. Critérios de Aceitação

• O usuário deve estar logado
• Somente a PRC tem autorização para editar os períodos
• Deve haver um período de alocação, de ajuste de alocação e letivo
• As datas de início e fim de cada período devem ser registradas
• O usuário PRC deve poder alterar o período

2.1.3 Responsáveis

• Daniel Marques Rangel
• Francisco Wallacy Coutinho Braz
• Gesiel dos Santos Freitas

2.2. EP01FE04TS10 - Refatorar sala (5pt)

2.2.1. User Story

Eu como desenvolvedor desejo refatorar sala com a finalidade de adicionar categoria às salas.

2.2.2 Responsáveis

• Ateldy Borges Brasil Filho
• Bruno Matias Casas

2.3. EP01FE02TS09 - Refatorar turma (5pt)

2.3.1. User Story

Eu como desenvolvedor desejo refatorar turma com a finalidade de adicionar categoria às turmas.

2.3.2 Responsáveis

• Ateldy Borges Brasil Filho
• Bruno Matias Casas

3. Indicadores do processo

3.1. Análise do Scrum Master

Houve uma repontuação de todo o backlog, tendo em vista que o time percebeu que a pontuação inicial não refletia na melhor estimativa da dificuldade real. Pode-se notar bem isso na TS04 - Refatorar Folha de Estilo que sua primeira pontuação foi 13pt e depois da repontuação se tornou 1pt. Com isso foi verificado o mau planejamento em sprints anteriores e foi notado o atraso do time em relação ao concluído total do projeto. O velocity do time teve um baixo rendimento, já que as histórias concluídas passadas foram repontuadas e em media diminuíram seus pontos e as não concluídas aumentaram.

Devido aos atrasos, foram planejadas nessa sprint mais pontos que do que o velocity propõe. Isso aconteceu devido a duas histórias que foram repontuadas muito acima do anterior e estavam de dívida da sprint anterior. Essas histórias são EP01FE01US01 - Realizar alocação e EP01FE01US02 - Visualizar alocação que juntas somam 34pt. Tendo em vista a dificuldade dela foram alocados três membros para sua realização. Elas não foram concluídas, pois houve a necessidade de remodelar os relacionamentos das classes do projeto, o que ocupou tempo. Nesse período foram desenvolvidas duas versões de um modelo que exemplifica visualmente os relacionamentos.

Versão 1.0

Versão 2.0

Foi desenvolvido também parte do código deste. Ficou acordado (para o bom andamento das histórias) a troca de alguns membros dessas histórias.

As histórias técnicas adicionadas durante a sprint ocorreram por pedido, devido a grande relação com a história EP01FE04US31 - Manter Categoria, pelo Bruno Matias Casas que se comprometeu com a entrega e teve nesta sprint uma alta produtividade, junto ao Ateldy Borges Brasil Filho. A história adicionada no primeiro standup, teve que ser adicionada para que as historias da FE01 pudessem evoluir. Esta também foi concluída com sucesso.

Nessa sprint tivemos os primeiros grandes problemas com falta de comprometimento, onde nos standups muitos membros faltavam e não avisavam. Os que faltavam e não avisavam foram em sua maioria desenvolvedores de GPP, os que tiveram maior falta nos standups foram os membros Gesiel dos Santos Freitas e Lucas Andrade Oliveira. No caso do Gesiel, os membros que deveriam ter trabalhado com ele, não sabiam informar as atividades dele, pois ele estava ausente. No caso do Lucas, ele trabalhou só em uma história de pontuação baixa, em certo momento eu pedi para que outros membros o ajudassem quando terminasse, mas isso não ocorreu, pois todos estavam com muita carga.

Durante os standups teve também o problema de em uma de suas ocorrências ter que ser remarcado por falta de membros, que não justificaram. Nessa ocorrência, no local marcado haviam apenas:

• Vinicius Pinheiro da Silva Correa
• Iasmin Santos Mendes(Não obrigatória a presença)
• Ateldy Borges Brasil Filho

Os que não foram, mas avisaram foram:

• Caio Felipe Dias Nunes
• Rodrigo Dadamos Lopes da Silva
• Lucas Andrade Oliveira (justificado - estágio)
• João Paulo Busche da Cruz (Não obrigatória a presença)

Os que nem avisaram, ou falaram depois do horário foram:

• Bruno Matias Casas
• Carlos Enrique Rodrigues Aragon
• Daniel Marques Rangel
• Francisco Wallacy Coutinho Braz
• Gesiel dos Santos Freitas
• Vinícius da Silva Carvalho

Pode-se notar que no geral houve uma falta de comprometimento nesta sprint, mas que em alguns casos ocorreu devido a provas. Contudo alguns membros se afastaram por completo.

3.3. Analise do Product Owner

Mediante as dificuldades enfrentadas na sprint 2 referentes ao alinhamento entre a visão do projeto da cliente com a equipe de desenvolvimento, essa sprint foi marcada pela remodelação e sincronização da visão da equipe sobre o software solicitado. Para tal, desenhou-se os processos de Alocar Sala e Solicitar Sala, os quais ilustraram de maneira clara quais e quando as regras de negócios deviam valer no sistema. Com a aprovação da cliente sobre os processos desenhados, a equipe voltou a desenvolver o software com segurança sobre o produto a ser entregue. Uma mudança adotada em relação as sprints anteriores, é que os processos foram modelados de uma visão genérica independente de como o sistema iria funcionar, o que possibilitou para a equipe o entendimento sobre o contexto do software. Em relação ao desenvolvimento das funcionalidades, a equipe passou a se comunicar bastante com a Product Owner, discutindo bem o protótipo e buscando atender a visão do usuário perante o sistema.

3.3. Burndown da sprint

Clique aqui para ver maior

3.4. Velocity da Sprint

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

Clique aqui para ver maior

3.5. Quadro de Conhecimento

Clique aqui para visualizar maior

4. Retrospectiva

4.1. Pontos Positivos:

• Aprimoramento no framework rails
• Pareamento
• Membros multitasks
• Maior comunicação entre os membros com a Product Owner
• Fluxo do kanban
• Colaboração intensa entre alguns membros

4.2. Pontos Negativos:

• Nivelamento do conhecimento no front
• Falta de Tempo (Faculdade)
• Falta de comprometimento com os standups
• Falta de comprometimento dos desenvolvedores de GPP
• Lucas Andrade Oliveira não contactou a Product Owner para verificar protótipo
• Poucos participaram (desenvolvedores de GPP)

4.3. Melhorias:

• Participação dos membros (GPP)
• Foco nas reviews
• Maior comunicação

5. Métricas

5.1 Cobertura de Testes

A cobertura deste a sprint passada diminui, pois mais métodos foram adicionados na session_helper, o quais a equipe ainda estão com dificuldade para realizar. Porém o resultado ainda e aceitavel, pois muitas histórias foram concluídas e todas funcionalidades acrescentadas foram testadas.

5.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	8.1	0
school_rooms_controller.rb	4	0
allocations_controller.rb	0	0
sessions_helper.rb	5.9	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
allocation_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
allocation.rb	0	0

Nessa sprint a complexidade de alguns arquivos subiram, porem como a complexidade destes arquivos ainda estão abaixo do limite estabelecido, não foi estabelecida nenhuma medida de reação.

5.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 não ocorrem em arquivos relevantes para o projeto, com exeção da users_controller.

5.4 Checkstyles

Após a inclusão da ferramenta do rubocop na integração contínua, para que as histórias sejam dadas como concluída elas não podem mais haver ofensas. Assim mesmo com a adição de arquivos não é detectada nenhuma ofensa.

5.5 Falhas de Segurança

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

5.6 Smells

Houve uma pequeno aumento no número de smells, isso ocorre pelo fato de mais arquivos terem sidos adicionados no projeto.