Planejamento Sprint 2 - Measurement-and-Metrics-2018-1/2017.1-SIGS GitHub Wiki

1. Introdução

Número da Sprint: 2

Data de Início: 06/05/2017

Data de Término: 13/05/2017

Duração: Uma semana

Pontos Planejados: 29

Pontos Adicionados (Dívida): 0


2. Papéis

Scrum Master:

Tracker:

Product Owner:

Desenvolvedores

3. Histórias planejadas

Todas as histórias de usuário contem um processo que indica seu funcionamento e este pode ser encontrado em Processos

3.1.1. User Story

Eu como coordenador(a) e Assistente de departamento desejo realizar alocação, com a finalidade de ministrar as disciplinas do meu curso.

3.1.2. Critérios de Aceitação

  • O usuário deve estar logado
  • O coordenador só pode alocar salas para turmas do curso que ele coordena
  • O Assistente de departamento pode alocar sala para qualquer disciplina que seja do seu departamento
  • O coordenador só pode alocar salas pertencentes ao departamento do seu curso
  • O Assistente de Departamento só pode alocar salas pertencentes ao seu departamento
  • Não pode haver mais de uma alocação na mesma sala no mesmo horário
  • A menor unidade de tempo na seleção do horário é 10 minutos
  • Os cursos diurnos devem ocorrer no horário de 8h às 18h, enquanto que os noturnos vão das 18h às 23h
  • O usuário deve poder filtrar a sala por um recurso
  • Informações da sala como descrição e os recursos a mais, além o filtrado, devem ser exibidas
  • Se não houver mais salas o sistema deve informar e direcionar para a EP01FE01US05

3.1.3. Responsáveis

3.2.1. User Story

Eu como Coordenador e Assistente de Departamento desejo visualizar a alocação de uma disciplina, com a finalidade de saber quais turmas e onde serão ministradas as aulas naquele período.

3.2.2. Critérios de Aceitação

  • O usuário deve estar logado
  • Ao selecionar uma disciplina devem ser listadas todas as turmas daquela disciplina, juntamente com seus respectivos horários e salas alocadas para cada horário
  • Atualizar view da US Visualizar Sala com grade horária da sala

3.2.3. Responsáveis

3.3.1. User Story

Eu como Coordenador e Assistente de Departamento desejo alterar as informações de uma turma, com a finalidade de garantir a consistência dos dados no sistema.

3.3.2. Critérios de Aceitação

  • O Coordenador só pode alterar as turmas que são exclusivas do curso dele
  • O Assistente de Departamento pode alterar somente as turmas de cursos do seu departamento.
  • Não se pode ter duas ou mais turmas com nomes iguais

3.3.3. Responsáveis

3.4.1. User Story

Eu, como desenvolvedor, desejo adequar o projeto à folha de estilo, para manter a padronização do código.

3.4.3. Responsáveis

4. Presença na reunião de Planejamento

Presente Membro
presente Ateldy Borges Brasil Filho
presente Bruno Matias Casas
presente Caio Felipe Dias Nunes
presente Carlos Enrique Rodrigues Aragon
presente Daniel Marques Rangel
presente Francisco Wallacy Coutinho Braz
presente Gesiel dos Santos Freitas
presente Iasmin Santos Mendes
presente João Paulo Busche da Cruz
presente Lucas Andrade Oliveira
ausente Rodrigo Dadamos Lopes da Silva
presente Vinícius da Silva Carvalho
presente Vinicius Pinheiro da Silva Correa

5. Quadro de conhecimento do Inicio da Sprint

quadro de conhecimentos Clique aqui para visualizar maior

6. Mudanças

6.1. Daily Meeting

Foi acordado no começo da sprint um horário fixo e um local fixo para todos os standups. Tendo como foco uma melhor organização de seu funcionamento.

6.2. Integração Contínua

Foi adicionado ao travis-ci a verificação e validação dos testes de aceitação automatizados

6.3. Kanban

Para melhor identificar os gargalos do time, o kanban foi refatorado de modo que os boards direcionassem o trabalho. A nova segmentação do kanban contempla Sprint Backlog, atividades da sprint que devem ser feitas, Prototype, momento em que será desenvolvido o protótipo da funcionalidade, Development, momento em que o time estará efetivamente desenvolvendo a funcionalidade (full-stack), Unit Test, momento em que os testes unitários estarão sendo feitos, Acceptance Test momento em que os testes de aceitação estarão sendo feitos, Revision, momento em que é aberto o Pull Request para a branch development e o Tracker da sprint irá analisar no código os indicadores de qualidade, podendo solicitar refatoração ao time ou aceitar o pull request e movendo o cartão para Done.

Kanban novo Clique aqui para visualizar maior

6.4. Uso de Issues e Milestones

Para melhor rastreabilidade foi definido que seriam adotados a utilização de Issues e Milestones. Em nosso contexto foi definido como Milestone o Épico e como Issue a história de usuário. Cada issue deve estar em sua milestone e conter os membros do time responsáveis por ela.

6.5. Commits

Com a implementação de issues por historia, foi definido um novo formato no commit, onde utilizaríamos a rastreabilidade do commit na issue. O novo formato é:

issue #< número >: < mensagem >

⚠️ **GitHub.com Fallback** ⚠️