Lembrando: O trabalho será principalmente avaliado com relação a aderência a um processo e justificativa das tomadas de decisões! Esta parte da avaliação equivale a 60% do total.
Sendo assim, que processo seguir?
Aqui temos algumas referências simples de entender.
XP
Dentro do espírito de simplicidade, um dos Valores XP, a quantidade de artefatos na XP é bastante reduzida. Na verdade, na XP nós não falamos realmente de artefatos como tais. Exceto pelo código de produção, todos os outros artefatos produzidos pelo processo implicam em trabalho que é tangencial à meta final, um produto executável. Em teoria, todo o resto deve ser considerado como opcional. O conjunto de artefatos apresentado aqui é comumente usado, pelas equipes XP, para entregar software de forma eficiente. Como regra, tente limitar a quantidade de esforço colocado em qualquer trabalho tangencial a menos que seja comprovado que ele melhore o processo, de alguma forma demonstrável.
Veja aqui os artefatos que fazem parte do XP. Isto deixa evidente a aderência ao processo utilizado, se utilizado.
Link XP
SCRUM
Scrum é um framework para desenvolver e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles apóiam o Guia do Scrum.
Veja aqui os artefatos que fazem parte do SCRUM. Isto deixa evidente a aderência ao processo utilizado, se utilizado.
Link SCRUM 1
Link SCRUM 2
O Kanban é baseado na ideia onde atividades em andamento devem ser limitadas. Um novo item só pode ser iniciado quando o item em andamento é finalizado ou quando uma função automática inicia o mesmo instantaneamente.
O Kanban, basicamente, tem como principal objetivo transformar o trabalho em andamento visível para toda equipe, criando um sinal visual que indica que o novo trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado.
Veja o artigo: Desenvolvimento Ágil de software: uma análise sintética a partir da metodologia Kanban
Dilbert usando Kanban (video)
Caro professor,
ResponderExcluirNão ficou claro para mim se este jogo deverá ser concretizado (ou seja, deve ser um aplicativo que poderá ser jogado) ou um planejamento com base em processos. Pode me esclarecer?
Ola,
ResponderExcluirA proposta de trabalho prático (TP) é termos o jogo implementado.
Porém temos que observar:
Que o TP é avaliado em 60% pela aderencia ao Processo utilizado e os 40% referentes a implementação do trabalho.
Deixei links sobre processos ágeis (XP e Scrum) onde você encontra artefatos que se tormam interessantes serem produzidos.
Use o nosso BLOG para evidenciar o que o grupo esta fazendo.
[]s
Sergio
Eu não sabia o que era artefato, talvez alguem aí também não saiba:
ResponderExcluirhttp://pt.wikipedia.org/wiki/Artefato_(desenvolvimento_de_software)
E agora já sabe Hudson?
ExcluirCaro Professor,
ResponderExcluirÉ obrigatório seguirmos a metodologia que você indicou no primeiro post (http://sbgames.org/sbgames2012/proceedings/papers/artedesign/AD_Full16.pdf) ?
Também não ficou claro pra mim se essa metodologia corresponde a um processo (ou seja, temos que usar OU OriGame OU XP OU Scrum OU Kansan), ou se ela é complementar aos processos (ou seja, temos que usar OriGame E (XP OU Scrum OU Kansan)).
Olá Clarisse,
ExcluirVocês devem seguir um processo sim! Acredito que um processo Ágil seja o mais aconselhável.
A Metodologia é o estudo dos métodos. Ou então as etapas a seguir num determinado processo. ;-)
A Metodologia define o Processo a ser executado. Assim sendo, o que usamos e/ou executamos durante o Desenvolvimento de um Software é um Processo baseado em uma Metodologia qualquer.
O link mencionado por você é uma informação de que existe um processo de como produzir um jogo. As vezes ficamos sem noção dos passos a executar, tarefas a realizar, e ali de forma reduzida tem estas informações. É apenas uma informação que pode ser seguida ou não, depende do grupo.
Mas vamos ao termo Processo.
Conforme Pressman, a Engenharia de Software (ES) é uma tecnologia em 3 camadas: processos, métodos e ferramentas. E a base de todas essas camadas é o foco na qualidade do software desenvolvido.
1.Processos: constituem um elo de ligação que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador. É o alicerce da engenharia de software.
2.Métodos: proporciona os detalhes de "como fazer" para construir o software;
3.Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos métodos (ferramentas CASE combinam software, hardware e um banco de dados).
O Guia PMBOK® define processo como sendo um “conjunto de atividades inter-relacionadas realizadas para obter um conjunto especifico de produtos, resultados ou serviços” (PMBOK 2004, pág. 373).
Segundo o IEEE, um processo é “uma sequencia de passos executada com um determinado objetivo”.
Para o CMMI, um processo é definido quando “tem uma descrição que é mantida”, ou seja, tem documentação que detalha o que é feito (produto), quando (etapas), por quem (papéis), os itens utilizados (insumos) e os itens produzidos (resultados).
Tem um link com material bem legal sobre isso em:
http://www.ceunes.ufes.br/downloads/2/mariateixeira-EC.Engenharia%20de%20Software.Conte%C3%BAdo%203.2011.2.pdf
-----------------------------------------------------------------------
Bom, se ainda estiver confusa, volte a perguntar!
-----------------------------------------------------------------------