Resumo das reuniões em pé da semana - esofteacher@sHoRTcut

Segue abaixo um resumo do pontos discutidos nas reuniões rápidas da equipe nessa semana:

• Definir o limite de cartões nas listas do Trello (tarefas nas colunas do Kanban):
  Foi decidido que a quantidade máxima de cartões em cada coluna/lista será 5. Uma exceção será feita para listas de cartões com recursos de referência para todo o projeto, que não terão um limite estabelecido.
• Avaliar viabilidade da entrega de instruções de ajuda dentro do jogo na primeira entrega (apresentação na quinta):
  Foi decidido que essa tarefa deveria passar para alguma sprint futura, que não teríamos tempo hábil para desenvolvimento e teste antes da primeira entrega.
• Discutir sobre estruturação dos testes no nosso processo e na ferramenta de gerenciamento (Trello):
  Será criado um cartão da história vinculado ao cartão das tarefas e também a uma tarefa de teste, que será, necessariamente, executado por alguém que não tenha participado daquele desenvolvimento. O cartão da história permanece na lista “Revisando” até a execução com sucesso dos testes (aceitação pelo testador), sendo movido depois para “Finalizado”, para, enfim, ser arquivada após o tempo necessário para que todos da equipe saibam do término.
• Avaliar a utilização das estatísticas do github como medida de produção:
  Foi decidido que é melhor contabilizar pelo esforço concluído nas tarefas de cada sprint, gerando o burndown chart que acompanhará o desenvolvimento.
• Verificar a viabilidade de contagem de Pontos de Função das histórias:
  Foi decidido que é melhor não contarmos os Pontos de Função e mensurarmos através de estimativas de hora, uma vez que o nosso programa não se assemelha com CRUDs, estando bem distante do domínio onde a contagem de PFs se mostra assertiva.
• Definir como separar tarefas do TP e do projeto do jogo:
  Foi decidido tratar igualmente no Trello (mas com marcadores próprios), visto que ambos tipos de tarefa consomem tempo e frequentemente necessitam de participação de mais de um membro da equipe. Para facilitar o acompanhamento dos esforços gastos / previstos da empresa, decidimos gerar dois Burndown Charts, um para o TP como um todo e outro para o desenvolvimento do jogo.
• Definir modo de levantar histórias e suas priorizações:
  Após troca de e-mail com a monitora (cliente), decidiu-se que nós mesmos iremos levantar os requisitos / histórias, simulando a sua chegada através do cliente, agindo como se a monitora e o “Dono do Produto” tivessem concordado com eles. Tentaremos priorizar as histórias com o cliente, definindo cada sprint (“corrida”), para depois dividirmos as tarefas.

Para ver mais: cartões das reuniões em pé um e dois.