Ata da 6ª Reunião - 17/10

Membros:

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

- Objetivos da reunião: 3º Sprint Review e 4º Sprint Planning

3º Sprint Review:

No Sprint Review é feita uma revisão do que foi feito durante a interação, em relação ao produto e em relação ao processo e é apresentado para o cliente. Também é relatados os impedimentos do processo e em relação a equipe.

Para esse Sprint conseguimos fazer tudo que foi feito e identificamos alguns detalhes que tem que ser mudados no processo.

Casos Feitos no Sprint Review:

1. Fazer um protótipo apresentável para o cliente. 20 pontos

O design visual do jogo foi completamente estabelecido. Neste novo build, é possível visualizar como os turnos progridem e ver as telas principais do jogo. A lógica em sí, não está neste build, pois exigia ainda outras informações desenvolvidas concomitantemente. Para a proxima build, pretendemos implementar a lógica do jogo e as telas que faltam.

Pode ser acessado aqui: https://www.dropbox.com/sh/yg4ayw6q8xtxdyf/12u5LTTtrt

2. Fazer o relacionamento de tarefas a se fazer no projeto e os cargos dos funcionários.  13 Pontos
3. Fazer o relacionamento dos bônus das tarefas para as outras tarefas.  13 pontos.

As tarefas 2 e 3 podem ser acessadas aqui:

https://docs.google.com/spreadsheet/ccc?key=0AlSic6iZbQWpdEJKWnpzVVYybzZkdW5xMlhic0dTNUE&usp=drive_web

4. Criar 10 funcionários exemplos para os primeiros testes - 8 pontos.
5. Criar 5 projetos exemplo para os primeiros testes - 8 pontos.

https://docs.google.com/spreadsheet/ccc?key=0As6gwZs8ta4GdFA3cjVlRnd5cmp6N2xOandEUlBreWc&usp=drive_web#gid=2

Também foram feitos três casos que foram necessários durante a iteração. O Professor relatou que o trabalho podia ficar grande de mais, e por isso dedicamos um tempo em simplificar os dados.

Os casos são os seguintes:

1. Fazer a simplificação das tarefas classes 1 e 2 Praxis. 3 Pontos.
2. Fazer a simplificação das tarefas classes 3 e 4 Praxis. 3 Pontos.
3. Fazer a simplificação das tarefas classes 5 e 6 Praxis. 3 Pontos.

Total de pontos feitos:    71.

Total pontos projetados: 62.

Impedimentos:

- Falta de comunicação na especificação jogo, tivemos pontos de divergência entre a equipe do Scrum.

Solução: Entramos em contato com o cliente/professor Sergio Crespo que sanou nossas dúvidas.

    - Integrantes não compareceram em reuniões;

Solução: Será colocado o nome apenas dos membros presentes nas atas das reuniões.

    - Integrante que conhece o Unity, estava ficando sobrecarregado, pois o framework é complicado e não trivial.

Solução: Ele criará as classes abstratas/interfaces e a implementação dessas será dividido com o grupo.

Problema no Processo

- Reunição semanal nem sempre ocorre:

Solução: Reuniões de curto intervalo de tempo após a aula, será equivalente ao Daily Scrum; E usaremos para marcar a reunião semanal.

- Não está sendo mostrado muita coisa relativa ao processo ao cliente:

Solução: Será feita ata de toda a reunição e será postada no Blog. Os passos do processo serão mostrados claramente;

4º Sprint Planning:

Sprint Planning é o planejamento do próximo Sprint. Nele é motado o Selected Backlog a partir do Product Backlog. O Product Backlog é uma lista que contém todos os possíveis casos de serem feitos no software, e nele tanto a equipe quanto o cliente podem adicionar casos. Ele pode ser encontrado aqui.

Já o Selected Backlog é um grupo de casos direcionados para um dos espaços do software, por exemplo melhora de uma funcionalidade. A partir do Selected Backlog a equipe escolhe quais destes casos podem serão feitos no Sprint, pois eles tem mais noção do tempo gasto para as coisas serem feitas.

Como nossa comunicação com o cliente não é completamente fluída, para facilitar, nós montamos o Selected Backlog e enviamos para o Sergio para ele verificar se está de acordo com seu desejo. Caso precise, faremos os ajustes.

Selected Backlog:

Integrar a programação ao GitHub.

Rodar dois turnos do jogo com dados reais.

Criar controle de reputação do jogador.

Criar controle do dinheiro.

Criar controle do salário.

Criar gerenciamento e alocação de tarefas.

Desenhar testes (TDD)

Integrar dados levantados ao jogo

Executar e explicitar os testes desenhados

Refinar interface gráfica

Colocar mensagens para o usuário, Instruções de Uso.

Rodar uma partida do jogo.

Criar interfaces que serão responsáveis pela implementação baixo nível do jogo.

Após o aceite do cliente será feita o Poker Planning. Nesta etapa será feita a votação de quantos pontos cada um dos casos tem e quais deles estão dentro do possível de ser feito em 2 semanas. Nesta etapa apenas a equipe vota.

 

G8Games

Apresentação G8 Games

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca
Vitor Paisante

Vinícius Garcia 

 

 

Bom no último Sprint definimos as seguintes tarefas a serem feitas no Selected Backlog:

1. Fazer um protótipo apresentável para o cliente. 20 pontos
2. Fazer o relacionamento de tarefas a se fazer no projeto e os papéis dos funcionários.  13 pontos.
3. Criar 10 funcionários exemplos para os primeiros testes - 8 pontos.
4. Criar 5 projetos exemplo para os primeiros testes - 8 pontos.
5. Fazer o relacionamento dos bônus das tarefas para as outras tarefas.  13 pontos.

Adiconalmente as tarefas propostas foram feitas as seguintes tarefas:

 

1. Simplificação das tarefas da classe do Praxis 1 e 2. 3 pontos.
2. Simplificação das tarefas da classe do Praxis 3 e 4. 3 pontos.
3. Simplificação das tarefas da classe do Praxis 5 e 6. 3 pontos.

 

Conversando com o professor Sérgio, ele disse que estava um pouco complexo a iterações que estavamos fazendo. Assim simplificamos um pouco para não perdermos muito tempo na confecção das tarefas.

O total de pontos feitos: 71 pontos feitos. Todos os casos deste sprint foram feitos.

O protótipo apresentável pode ser acessado aqui: https://www.dropbox.com/sh/yg4ayw6q8xtxdyf/12u5LTTtrt

 

A relação dos papés dos funcionários com as tarefas podem ser encontrado aqui, onde também se encontra a relação de bônus entre as tarefas:

https://docs.google.com/spreadsheet/ccc?key=0AlSic6iZbQWpdEJKWnpzVVYybzZkdW5xMlhic0dTNUE&usp=drive_web#gid=0

 

A criação dos 10 funcionários e 5 projetos podem ser encontrados aqui:

https://docs.google.com/spreadsheet/ccc?key=0As6gwZs8ta4GdFA3cjVlRnd5cmp6N2xOandEUlBreWc&usp=drive_web#gid=2

 

Hoje a noite iremos fazer o Sprint Review e o próximo Sprint Planning. Postaremos as decisões aqui.

Seminário Virtual - Grupo SpeedGames

Data: 17/10/2013
Integrantes: Júlio Albinati,
                  Paulo Bicalho,
                  Rubens Emilio

Nesse seminário, vamos explicitar o processo de desenvolvimento do nosso grupo, as tarefas já realizadas e a realizar, os artefatos gerados até então e o plano de testes que estamos seguindo.

1. Descrição do Processo

Detalhamos a nossa implementação do Kanban através de um diagrama que descreve o fluxo de atividades pertencentes ao processo.

Esse diagrama pode ser visualizado em: https://github.com/Speederama/EngSoft/blob/master/TioPastinhas/doc/OProcesso.pdf?raw=true

2. Atividades

As atividades realizadas, em desenvolvimento e a fazer podem ser visualizadas em: https://github.com/Speederama/EngSoft/blob/master/TioPastinhas/doc/kanbanFlow-17-10.png?raw=true

É importante notar que algumas tarefas estavam atrasadas, em especial as atividades relacionadas à elaboração da tela de configurações. Identificamos a causa desse atraso como a indisponibilidade de alguns dos membros da equipe, que estavam sob pressão de prazos curtos.

3. Artefatos Gerados 

Além do código fonte, geramos artefatos contendo:

 - Gestão de Requisitos: https://github.com/Speederama/EngSoft/blob/master/TioPastinhas/doc/avaliacao_requisitos_1.txt

 - Diagrama de Classes: https://github.com/Speederama/EngSoft/blob/master/TioPastinhas/doc/diagram.pdf?raw=true

 - Plano de Testes: https://github.com/Speederama/EngSoft/blob/master/TioPastinhas/doc/Planodetestes.pdf?raw=true

Seminário Virtual

Ola Pessoal, hoje teríamos seminário, mas estou viajando, sendo assim, cada grupo deve postar o seu seminário no BLOG!
Outra atividade:
Procurem evidenciar a sua aderência ao processo, para isso:
(a) Descreva o seu processo, com detalhes.
(b) Descreve baseado no seu processo as atividades que devem e foram realizadas
(c) Identifique o que foi gerado em cada fase do processo.

Muitas destas informações estão em posts anteriores, vale o copy/paste!

Abraços
Sergio

20th Booth Games

Detalhamento de Processo e Andamento do Grupo 20th Booth Games

Júlio César

Josué Costa

Yuri Pessoa

André Harder

    1)    Metas Genéricas

a)     Atingir metas específicas

b)    Institucionalizar o processo gerido

c)     Institucionalizar o processo definido

1.1)         Práticas Genéricas:

a.1) Executar práticas específicas:

        Práticas específicas detalhadas à frente.

b.1) Planejar o processo:

        O processo em andamento foi planejado conforme informado no primeiro seminário do trabalho, com poucas alterações.

Alterações:

·        Cronograma de entregas - Postagem semanal no Blog.

Motivos:

·    Pouca informação nova a ser adicionada no prazo curto de uma semana. Como grande parte do início do processo se resumiu na providência de recursos e treinamento, definiu-se que não havia material para postagem nas semanas referentes às fases de requisito e desenho do projeto.  

 As áreas referentes ao processo serão detalhadas à frente.

b.2) Prover recursos:

        Recursos providos:

·  Material de estudo da linguagem e engine de jogo escolhidos. Recurso provido.

·  Material relevante para o desenvolvimento de sprites. Recurso provido.

·        Material relevante para o desenvolvimento do background gráfico do jogo. Recurso provido.

·  Meio de comunicação entre os envolvidos. Recurso Provido.

·  Materiais para Gestão de Configuração, Gerência e Controle de Versões. Recurso Provido.

     

b.3) Atribuir responsabilidades

·        Desenvolvedor Chefe: André

·        Inspetor: Josué

·        Gerente de Testes: Júlio

·        Coordenador: uri

b.4) Treinar pessoas

     O treinamento foi realizado de forma individual por cada membro do projeto.

b.5) Gerir configurações

       Todos os recursos necessários à gestão de configurações já foram levantados. Até o momento, apenas as configurações referentes à implementação da arquitetura estão sendo geridas, uma vez que a fase de implementação teve início há apenas uma semana.

       As configurações de arquitetura estão sendo desenvolvidas pelo Gestor de Testes, o Desenvolvedor Chefe e o Coordenador do projeto.

b.6) Monitorar e controlar o processo

        O monitoramento e controle estão sendo realizados pelo Coordenador do projeto por meio dos recursos de interação virtual e as plataformas de controle de versões.

b.7) Avaliar objetivamente a aderência

        A avaliação de aderência é realizada em conjunto. Até o presente momento, é unânime a conformidade do andamento aos prazos e objetivos do projeto.

b.8) Rever status com direção

        Função da coordenação. Até o momento, a aderência do projeto ao processo permitiu rápidas revisões de status, sem grande impacto ao processo. A única alteração realizada para adequação do projeto ao processo em andamento foi descrita no item b.1. deste documento.

    2)    Áreas de Processo e Metas Específicas e Práticas Especificas:

2.1) Gestão de Requisitos:

            2.1.1) Entendimento dos requisitos:

                       Tomou-se como requisitos as informações constantes no enunciado do trabalho, divulgado no Blog da disciplina. Na posse de um documento escrito, avaliou-se a necessidade de uma oficina para apuração dos requisitos em posse, mas foi firmada a não necessidade de um encontro formal com o redator do documento. Os requisitos a serem atendidos são os requisitos de enunciado, os quais foram facilmente entendidos, visto a baixa complexidade dos mesmos e a alta liberdade conferida no desenvolvimento do trabalho.

2.1.2) Obter compromisso com os requisitos:

        Todo o processo foi desenvolvido com foco no atendimento aos requisitos. Porém, algumas dificuldades foram encontradas neste esforço: 

Dificuldades: Requisito de postagem constante no blog do trabalho.

Motivos: Falta de novidades a serem postadas nas fases de levantamento de requisitos, desenho e arquitetura.

2.1.3) Gerir alterações de requisitos:

         Nenhum requisito foi alterado até o momento, apesar de dificuldades no pleno atendimento a um deles. Entretanto, o atendimento pleno ainda é buscado pelo grupo.

2.1.4) Manutenção da rastreabilidade:

       Função da coordenação do projeto. Até o momento há conformidade entre o projeto e seus requisitos.

2.1.5) Identificar inconsistências:

      Até o momento, apenas uma inconsistência foi  identificada, a qual foi mencionada neste documento.

2.2) Planejamento de Projeto:

            2.2.1) Estabelecimento de estimativas:

Todos os prazos foram definidos no Kanban eletrônico, levando-se em conta os esforços necessários estimados e as metas do cliente. O Kanban eletrônico está acessível para visualização no DropBox do grupo.

                        2.2.2) Desenvolver o plano de projeto:

Também presente no Kanban eletrônico. O projeto foi planejado nas fases de Requisitos, Desenho, Desenvolvimento, Testes e Validação, com incrementos iterativos de fases, validados por um flag de chave unânime. Os conhecimentos necessários foram levantados na fase de requisitos, e cada membro do grupo buscou se adequar a este requisito interno. Os prazos foram definidos levando-se em conta possíveis riscos, e a gestão de dados encontra-se detalhada em postagens anteriores no blog, e mencionadas em itens anteriores deste documento.

                        2.2.3) Compromisso com o plano:

Prioridade no atual processo. O comprometimento, até o momento, rendeu conformidade com os prazos propostos.

            2.3) Monitoramento e controle

                        2.3.1) Projeto X Plano

                                   Até o momento, projeto e plano seguem conformes.

                        2.3.2) Ações corretivas:

   Função da coordenação. Até o momento, apenas uma ação corretiva foi necessária: foram alterados alguns prazos no plano, após a aferição do prazo de entrega do produto final.

            2.4) Medição e Análise

Prática prevista para a fase de desenvolvimento. Não é parte do plano qualquer medição de tamanho ou custo do programa, uma vez que não faz parte da ementa da disciplina ensinar como proceder com a mencionada prática. Portanto, apenas procedimentos de análise e tratamento de resultados foram definidas. Esta prática é função do Inspetor do projeto.

            2.5) Garantia de qualidade do processo e produto

O processo está sendo seguido à risca, com foco nos prazos e nos requisitos externos. Pode haver algumas falhas na transparência e na emissão de dados e resultados, mas isto é função do estado “aluno” dos envolvidos. Estamos aprendendo a lidar com processos nesta disciplina, portanto, falhas durante a execução da prática sobre a teoria são esperadas. Porém, é objetivo geral do grupo zelar pela qualidade do produto e conformidade do projeto.

            2.6) Gestão de configurações

            Já mencionado, e parte importante do processo. Todas as ferramentas utilizadas na gestão de configurações foram mencionadas em postagens no blog. Linhas de base foram definidas no Kanban. Auditorias são interpretadas como as opiniões dos docentes durante os seminários.

Últimas informações:

- Gostaria apenas de ressaltar um fator de avaliação que vem trazendo, particularmente a mim, algum transtorno: o pico de esforço. O transtorno causado se deve há: atualmente trabalho oito horas por dia como analista de sistemas na matriz da empresa Stoque Soluções Tecnológicas Ltda. Curso cinco disciplinas na UFMG, e, já no décimo período do curso, tenho este semestre para desenvolver meu Trabalho de Conclusão de Curso. Isto faz com que todo esforço despendido nas disciplinas deste semestre são, por si só, picos de esforço. Estamos focados em respeitar e nos adequar aos prazos da melhor forma possível, entretanto, o tempo pode apenas ser administrado de acordo com as demandas variáveis de cada semana.    

G8Games

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca
Vitor Paisante

Vinícius Garcia 

Professor,

        Estamos colocando detalhes do processo de maniera mais fácil de ser vizualizada. A seguir segue o Product Backlog do nosso trabalho. No Scrum o product backlog é um "documento" ou ferramenta para mostrar todos os casos possíveis de serem feitos no projeto, podendo ser feitos ou não dependendo dos Sprints e das iterações com o cliente.

A seguir segue o nosso product backlog em uma tabela no google drive, mais organizada que a anterior:

https://docs.google.com/spreadsheet/ccc?key=0As6gwZs8ta4GdEhqSXdnamVZVWQwUjM1RHpZVnpEdXc&usp=drive_web#gid=0

Neste documento tem duas planilhas. A primeira é o product backlog, a segunda são idéias gerais sobre o projeto, que podem ou não se tornar casos para o produck backlog.

G8Games

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante 
Tarefas a serem feitas

A seguir estão representadas as tarefas possíveis de serem feitas no projeto. Fizemos o apanhado de dados para o release final do jogo com os dados completos, caso haja continuidade no desenvolvimento do jogo. Para o release ao final do semestres pretendemos fazer a jogabilidade com dados mais simples então iremos diminuir o número de dados para simplificar.

Requisitos:

1.  Determinação do Contexto;
2.  Modelagem de Negócio;
3.  Modelagem de Sistema;
4.  Definição de Escopo;
5.  Glossário;
6.  Diagrama de Contexto;

7.  Prototipagem dos requisitos;
8.  Levantamento dos requisitos funcionais;

9.  Detalhamento dos requisitos de interface;
10. Detalhamento dos requisitos não-funcionais;
11.  Registro dos requisitos não-funcionais;

12.  Verificar se os requisitos atendem os critérios de qualidade;
13.  Verificar se fornecem informação suficiente;

14.  Apresentação requisitos para os usuários, podem ser feitas    possíveis alterações;

Análise:

1.  Preparação da Inspeção;
2.  Análise do modelo do problema;
3.  Reuniões de inspeção
4.  Registro de anomalias
5.  Relatório de inspeção da análise;

6.  Determina operações realizadas para as classes;
7.  O que essas operações devem fazer;
8.  Fazer os Casos de Uso e suas interações;

9.  Retrabalho - Remove anomalia ou justificam a não remoção;
10.  Conferência do retrabalho

Desenho:

1. Atender os requisitos não funcionais
2. Modelar a solução
3. Geração de artefatos do Modelo da Solução
4. Reutilização do código
5. Criar o Desenho Arquitetônico
6. Criar o Desenho Externo
7. Criar o Desenho das entidades
8. Criar o Desenho da persistência
9. Preparação da inspeção
10. Inspeção do desenho externo
11. Retrabalho - Remove anomalia ou justificam a não remoção;
12. Conferência do retrabalho
13. Criar o Desenho estrutural interno
14. Criar o Desenho comportamental interno
15. Inspeção do desenho interno

Implementação:

1. Programação
2. Integração (big-bang, bottom-up, top-down)
3. Criar o Desenho detalhado
4. Teste de Unidade
5. Realizar teste de caixa cinza
6. Realizar teste de caixa branca
7. Realizar teste de caixa preta
8. Inspeção de implementação
9. Reuniões de Inspeção
10. Revisar código
11. Revisão do desenho detalhado
12. Documentação para usuários
13. Criar manual para usuário
14. Criar documentação on-line
15. Fornecer ajuda on-line
    
    As tarefas de Implementação e Testes estão sendo feitas por um integrante do grupo e serão postadas brevemente.