Enunciado: Quarta Parte do Projecto
Prazo de entrega: 20:00 do dia 14 de Maio de 2014.
A entrega da quarta parte do projecto faz-se via SVN utilizando o repositório disponibilizado para cada grupo. Após cada grupo ter colocado no seu repositório o código correspondente à quarta parte do projecto de ES e ao segundo projecto de SD, deve marcar esse código criando a tag ''R_4''.
Verssão local do serviço RegistoFactura: registofatura.tgz. Este arquivo tem código que os grupos de ES e SD já têm e que portanto poderão não necessitar.
Pequenas alterações ao projecto:
- Os grupos que sejam de ES e SD devem incluir no estado inicial do serviço externo ChequeRefeição remoto os seguinte dados:
- O utilizador 'zeze' deverá dispor de 10 cheques de EUR 10 já emitidos;
- A utilizadora 'mariazinha' deverá dispor de 4 cheques de EUR 25 já emitidos.
- Quando é realizado um pagamento através do portal, deve ser apresentado ao utilizador o número de serie e de sequência da fatura emitida relativa à compra efectuada.
Enunciado: Quarta Parte do Projecto
Prazo de entrega: 20:00 do dia 14 de Maio de 2014.
A entrega da quarta parte do projecto faz-se via SVN utilizando o repositório disponibilizado para cada grupo. Após cada grupo ter colocado no seu repositório o código correspondente à quarta parte do projecto de ES e ao segundo projecto de SD, deve marcar esse código criando a tag ''R_4''.
Verssão local do serviço RegistoFactura: registofatura.tgz. Este arquivo tem código que os grupos de ES e SD já têm e que portanto poderão não necessitar.
Pequenas alterações ao projecto:
- Os grupos que sejam de ES e SD devem incluir no estado inicial do serviço externo ChequeRefeição remoto os seguinte dados:
- O utilizador 'zeze' deverá dispor de 10 cheques de EUR 10 já emitidos;
- A utilizadora 'mariazinha' deverá dispor de 4 cheques de EUR 25 já emitidos.
- Quando é realizado um pagamento através do portal, deve ser apresentado ao utilizador o número de serie e de sequência da fatura emitida relativa à compra efectuada.
Planeamento ágil SCRUM aplicado ao Projecto
O planeamento da gestão da 4ª parte do projecto deve ser feito aplicando a metodologia SCRUM e deve ser realizado através de uma cópia da folha de cálculo disponibilizada no Google Docs:
Para isso, cada grupo deverá criar uma cópia da folha de cálculo acima indicada, disponíıvel no Google Docs.
A cópia deve ser renomeada com o nome do repositório do grupo (C-ES-SD-SD).
Por exemplo, o grupo 1 de ES, cujos alunos fazem parte dos grupos 2 e 3 de SD, teriam uma folha de cálculo chamada:
- ES 2013-14 SCRUM T-01-02-03
A folha 'Check' dessa folha de cálculo deve ser actualizada com os nomes dos membros do grupo que depois são utilizados automaticamente nas restantes folhas.
Deve ser enviado, o mais cedo posíıvel, um e-mail para os e-mails gerais das cadeiras de ES e SD com o assunto 'SCRUM do grupo C-ES-SD-S' (nome do repositório) onde indicam o link para a versão do documento do grupo (que deve ser previamente configurado como sendo acessível a quem tenha o link).
O não envio deste e-mail em tempo útil corresponderá a uma avaliação de 0 (zero) da componente de gestão de projecto.
Cada aluno deve indicar diariamente na folha de cálculo do grupo o trabalho realizado para ES e SD (horas, tarefas, etc.) na folha 'Actual Spent Time' e as estimativas das tarefas que lhe foram atribuidas na folha do 'Sprint' em curso.
Cada grupo deve actualizar semanalmente, no início de cada Sprint, o planeamento do projecto.
Esta actualização inclui o resultado da execução do Sprint da semana anterior e o planeamento da execução do Sprint da semana que começa.
Semanalmente, no início de cada Sprint, cada grupo deve também produzir, um documento de texto com a retrospectiva do Sprint anterior, onde indicam o que correu bem e de acordo com o planeadoe o que correu mal ou conduziu a atrasos.Esse documento deverá ser colocado na sub-directoria 'sonet/trunk/info' do repositório do projecto sonet.
- Identificar as funcionalidades a concretizar e preencher o Product BackLog.
Exemplo de funcionalidade: 'Votar publicação'. - Para cada funcionalidade criar uma história, atribuindo-lhe um "título" sucinto
e uma descrição sucinta do ponto de vista do utilizador.
As histórias devem ser definidas utilizando o formato descrito nas aulas teóricas.
Exemplo:
"Eu, como agente individual, quero votar numa publicação existente à qual tenho acesso (seja porque sou amigo do dono, seja porque ela é pública), para aumentar a popularidade dessa publicação."
Adicionar a história também ao board. - Cada grupo deve estimar, em equipa, o esforço necessário para executar cada história.
A estimativa deve ser feita em Tempo Ideal, utilizando o Poker de estimação (cartas disponíveis para impressão) (versão com o logotipo antigo). - Calcular a disponibilidade de trabalho de cada elemento do grupo para a primeira semana de trabalho
e preencher a matriz de disponibilidade SCRUM para a equipa. - Seleccionar as histórias que vão fazer parte do Primeiro Sprint, considerando:
- as disponibilidades indicadas por cada membro da equipa;
- que cada Sprint começa à segunda-feira e tem uma semana de duração;
- tendo em conta as prioridades de cada história.
- Criar o Sprint Backlog através da expansão das histórias que decidiram incluir no Sprint em tarefas (Task Expansion)
- Estimar, em equipa, o esforço (em pessoa/hora) de cada uma das tarefas escolhidas para fazer parte do Sprint. Atenção que o esforço é medido em pessoa/hora e não equipa/hora, o que significa que tarefas feitas em pares ou grupos devem ver o seu valor multiplicado pelo número de pessoas envolvidas.
Cada tarefa deve ter no mínimo 30 minutos e no máximo 8 horas.
Cada tarefa pode ser atribuída a 2 elementos do grupo para permitir pair-programming. - Se a soma de estimação de todas as tarefas de um dado Sprint ultrapassa a disponibilidade de trabalho dos elementos da equipa, então é necessário retirar histórias das escolhidas para o Sprint até que o número de horas total estimado doSprint seja inferior ao total de horas disponíveis dos membros do grupo que foram calculadas anteriormente.
- Actualizar a execução do Sprint actual todos os dias.
O estado da execução do Sprint actual deve corresponder ao indicado na folha de cálculo.
Assim, para cada dia de trabalho, cada elemento do grupo deve indicar quantas horas trabalhou nesse dia
e indicar quantas horas de trabalho é que estima que ainda faltam nas tarefas em que esteve envolvido nesse dia. - Sublinha-se que o sucesso deste tipo de metodologias depende bastante da qualidade das estimativas, pelo que se recomenda que os alunos sejam o mais realista possível.
NOTA:
De modo a poderem planear o desenvolvimento da 4ª parte do projeto usando o método SCRUM convém ter histórias que possam ser implementadas numa semana.
O planeamento SCRUM a realizar por cada grupo ES+SD deverá incluir o planeamento do desenvolvimento dos requisitos não-funcionais de SD. Dado que o desenvolvimento de cada requisito não-funcional de SD deve, em princípio, ocupar mais do que uma semana, aconselha-se cada grupo a analisar o problema que têm para resolver em SD de forma a identificar histórias mais pequenas que possam ser desenvolvidas e testadas no período de uma semana. Podem contar com o apoio dos professores de SD nas aulas de laboratório.
Esta identificação das histórias mais pequenas deve ser feita com base na análise do documento a produzir no primeiro sprint por cada grupo com a proposta/esboço da solução para cada um dos requisitos não-funcionais de SD. Assim, cada requisito não-funcional poderá corresponder a mais do que uma história. Esta decomposição dependerá da análise efetucada por cada grupo.
Esta estratégia permitirá adicionalmente um desenvolvimento incremental da solução de SD, para a qual também poderão aplicar técnicas de refatorização.
EXEMPLO:
Pode também consultar este Exemplo de SCRUM para RELEASE_2 do projecto do ao passado.
FAQ
Como resolver o seguinte erro: No source code is available for type javax.xml.datatype.XMLGregorianCalendar; did you forget to inherit a required module?
Resposta: Tal como indicado na primeira aula sobre o GWT, todo o código que pode ser executado no browser vai ser convertido automaticamente pelo GWT para javascript. As directorias que incluem este código devem estar indicadas no ficheiro que especifica o módulo GWT (RestGWT.gwt.xml na maior parte dos grupos) usando a tag source. O tipo javax.xml.datatype.XMLGregorianCalendar não está nestascondições e deve estar a ser referenciado em algum código que vai ser executado no browser. Por isso, referências a este tipo ou a outras classes relacionadas com o serviço RegistoFatura não deverão ser feitas em código a ser executado no cliente.