Skip to content

Planejamento Sprint 3

VinyPinheiro edited this page May 22, 2017 · 3 revisions

1. Introdução

Número da Sprint: 3

Data de Início: 13/05/2017

Data de Término: 20/05/2017

Duração: Uma semana

Pontos Planejados: 6

Pontos Adicionados (Dívida): 34


2. Papéis

Scrum Master:

Tracker:

Product Owner:

Desenvolvedores

3. Histórias planejadas

3.1.1. User Story

Eu como Coordenação e PRC desejo categorizar minhas salas e turmas com a finalidade de ter conhecimento sobre os recursos, respectivamente, ofertados e necessários para cada uma delas.

3.1.2. Critérios de Aceitação

  • O usuário deve estar logado
  • A categoria deve conter um nome
  • Somente a PRC pode criar, editar e excluir as categorias
  • Deve ser possível adicionar categorias as salas
  • Deve ser possível adicionar categorias as turmas
  • Se uma categoria for excluída todas as turmas e salas associadas a ela devem perder essa categoria

3.1.3. Responsáveis

3.2.1. User Story

Eu como Coordenação desejo excluir uma turma, com a finalidade de garantir a consistência das disciplinas ofertadas.

3.2.2. Critérios de Aceitação

  • O usuário deve estar logado
  • Uma mensagem de confirmação alertando o usuário deve ser exibida
  • Uma turma só pode ser excluída por um membro da Coordenação que pertença ao mesmo departamento da turma

3.2.3. Responsáveis

3.3.1. User Story

Eu como Coordenação e PRC desejo excluir uma sala com a finalidade de retirar salas indisponíveis para alocação do sistema.

3.3.2. Critérios de Aceitação

  • A coordenação só pode excluir salas do seu próprio departamento
  • A prefeitura só pode excluir salas do espaço comum
  • Uma mensagem de confirmação deve ser exibida ao usuário

3.3.3. Responsáveis

4. Histórias Adicionadas (Dívida)

Na última reunião com a cliente houve uma mudança na regra de negocio o que resultou na mudança dessas histórias e de seus crotérios.

4.1.1. User Story

Eu como membro do departamento desejo realizar alocação, com a finalidade de ofertar as disciplinas e extensões do meu departamento para os cursos da UnB.

4.1.2. Critérios de Aceitação

  • O usuário deve estar logado
  • A Coordenação só pode alocar salas que pertençam ao seu departamento
  • A prefeitura só pode cadastrar Extensão para alocar na área comum
  • A extensão deve ter periodicidade:
    • Diária
    • Semanal
    • Mensal
  • Pode haver mais de uma turma alocada em uma sala no mesmo horário se essas turmas forem da mesma disciplina e se somado o número de vagas de cada turma, o valor não exceder a capacidade da sala.
  • A menor unidade de tempo é 1h
  • Os cursos diurnos devem ocorrer no horário de 8h às 18h, enquanto que os noturnos vão das 18h às 23h
  • A periodicidade dos horários relacionados a uma turma é semanal
  • A busca de sala deve levar em consideração as características da turma
  • A busca de salas deve levar em consideração:
  • A ala dos cursos relacionados a turma
  • O número de vagas
  • Os recursos definidos para a turma
  • Turmas da mesma disciplina alocadas no mesmo horário*
  • Caso o período de Alocação Global (Alocação e Ajuste de Alocação) for o vigente, não pode haver alocação de extensão entre as datas de início e fim do período letivo.
  • Se não houver mais salas o sistema deve informar e direcionar para a EP01FE01US05

4.1.3 Responsáveis

4.2.1. User Story

Eu, como usuário desejo visualizar o que está alocado em um determinado horário com a finalidade de ter conhecimento sobre a atividade corrente naquele horário.

4.2.2. Critérios de Aceitação

  • O usuário deve estar logado;
  • Se a alocação for um projeto de extensão deve ser exibido o projeto de extensão, o responśavel, o número de vagas e a periodicidade do projeto;
  • Se a alocação for uma turma deve ser exibido a turma, a disciplina, o departamento, número de vagas, cursos associados e recursos exigidos para a turma;
  • Deve ser exibido todos os horários e dias relacionados a aquele projeto/turma;
  • Se houver mais de uma turma associada a alocação, todas devem ser exibidas.

4.2.3. Responsáveis

5. 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
presente Rodrigo Dadamos Lopes da Silva
presente Vinícius da Silva Carvalho
presente Vinicius Pinheiro da Silva Correa

6. Quadro de conhecimento do Inicio da Sprint

quadro de conhecimentos Clique aqui para visualizar maior

7. Mudanças

7.1. Repontuação do Backlog

A equipe notou que a pontuação inicial do project backlog não retratava a estimativa de esforço mais próxima do real e então optou pela repontuação de todo o backlog de modo que as histórias tenham uma pontuação mais próxima do esforço necessário.

7.2. Refatoração do Backlog

Na sprint passada foi encontrado um problema no entendimento do produto, onde em 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 foi anotado todas as mudanças e então no planejamento dessa sprint o backlog do produto teve que ser refatorado.

7.3. Papéis

  • Product Owner: Depois da reunião com a cliente foi definido que os processos seriam desenhados visando o sistema como um todo e não apenas focado nas histórias da Sprint corrente. Portanto nesta sera feito pelo Product Owner os primeiros processos gerais. que podem ser localizados na aba Processos.
Clone this wiki locally