Double Jumpers #18: Scrum + Games
Como promedito no DoubleJumpers #16 sobre processo de produção, introduzimos aqui a metodologia ágil mais conhecida como Scrum, método utilizado por muitas empresas de games e uma com a qual tivemos muito contato e decidimos partilhar. Apresentamos e discutimos como usar o Scrum na produção de um jogo – que não é nada trivial, como vocês perceberão!
Drops:
- Sony premia fãs “leais”
- O jornalismo investigativo na mídia de games
- Shinji Mikami entra para ZeniMax
Tema: Scrum + Games
Tempo: 76 minutos
Double Jumpers #18 – Scrum + Games – (Qualidade Alta) – 69MB
(Botão direito, “Salvar como…”)
Links:
cateogories: DoubleJumpers
Gilliard Lopes
November 3, 2010 at 16:04
Bom podcast mas bem difícil de comentar, pois as experiências com Scrum que eu conheço sempre variam muito dependendo do time, tamanho da empresa, tipo de jogo, e muito mais.
Boa sorte lá no SBGames e por favor mandem meu abraço pro pessoal da Hoplon que vocês encontrarem por lá!
Fernando Secco
November 4, 2010 at 07:34
Sempre acho difícil falar de Scrum pois as experiências são sempre diferentes. Nos lugares em que trabalhei eles sempre tinham variações da metodogolia e como acompanhar as task e o backlog. Escolhas onlines como sistemas de track de bugs eram os mais comuns.
Pelo que entendo, Scrum é para ser um update rápido e pratico. Se tiver consumindo muito tempo é melhor adaptar ele para suas necessidades.
Rafael "Barry&q
November 4, 2010 at 18:41
Só eu vou entender a interna… haha.
Por todas as palestras que vi e coisas que li sobre o Scrum, só conclui que o objetivo dele é manter as coisas simples. Ou seja:
- Planeje com a equipeo que vai fazer durante a semana, de acordo com a visão do diretor/produtor.
- Quebre o planejamento em tarefas não necessariamente diárias, com cada um se responsabilizando por entregar o que se comprometeu no fim do sprint.
- Diariamente, comente com a equipe o que foi feito e o que está te atrapalhando.
- Ao fim do sprint, ANTES de planejar um novo, reveja o que deu certo e errado durante o sprint anterior.
Se começar a haver muitas reuniões, muita terminologia (pior: em inglês), muita burocracia, quer dizer que o Scrum não está sendo feito. fazer "meio" scrum é o mesmo que não fazer.
E Artemis… deixa eu ver se entendi: você PAGOU pra ver um streaming da Blizzcon?
Gilliard Lopes
November 4, 2010 at 22:14
Vou concordar discordando… Não acho que exista “meio-Scrum”, até porque o Scrum foi concebido como um conjunto de princípios e artefatos, não como um método rígido a ser seguido. Boris Gloger, um dos criadores do Scrum de quem obtive a certificação Scrum Master, nos lembrava a todo momento durante o curso que os princípios são o que realmente importa, e as ferramentas somente ajudam a realizá-los na prática. Se você tiver os princípios na cabeça, não importa que utilize outras técnicas para realizá-los.
Por exemplo, não importa que o tamanho da Sprint não seja o recomendado no Scrum, contanto que siga os princípios de ser pequeno o suficiente para simplificar o planejamento, e entregar uma versão “shippable” no fim. Não importa a composição do Daily Scrum, contanto que os princípios de identificar os impedimentos e manter o time atualizado sejam cumpridos. Esse é o único jeito de “adaptar [Scrum] para suas necessidades” como o Secco falou.
Isso dito, acho que o ponto do Barry está correto apesar de não concordar muito com a terminologia. Ele identifica alguns dos princípios (ou exemplos de sua utilização prática) ali em cima e argumenta que seguir apenas metade deles não leva a nada, o que eu absolutamente concordo. Não sobre o processo em si, o formato das reuniões ou as ferramentas; mas sobre os princípios.
Por isso é tão importante ler o manifesto ágil.
Outra coisa que faltou dizer: Scrum não é bala-de-prata, não vai ser o melhor método pra TODOS os casos. Estudar os princípios ajuda também a identificar se a metodologia se aplica ao teu projeto. Por exemplo, se esperamos que muitas mudanças sejam requeridas durante a produção; se temos um stakeholder de fora do nosso dia-a-dia para quem é importante demonstrar progresso incremental; se o time é pró-ativo o suficiente (ponto muito bem explorado no podcast); etc.
Rafael "Barry" Ventura
November 4, 2010 at 22:30
Não falei que seguir metade deles não leva a nada, falei que não levar o scrum a sério é o mesmo que não fazer Scrum.
Entendê-lo e aplicá-lo significa entendê-lo e aplicá-lo, e não “entender algumas coisas” e “aplicar algumas outras”. Ou então é um meio-scrum envolvido em uma bola de processos burocráticos, que no fim das contas é a mesma coisa de qualquer processo de produção, e não o Scrum. Falo por experiência própria.
E não tenho o certificado de Scrum master.
Sillentkill
November 8, 2010 at 02:11
Ficou muito massa o cast, principalmente com a atuação cheia de informações do Martin. Vou ter que escutar novamente pq realmente é mto conteúdo pra escutar e assimilar de uma só vez.
Gostaria de fazer uma pergunta meio especifica:
Qual é o tempo médio de reunião diária entre os devs do scrum que vcs fizeram por exemplo no freak? Vcs fizeram a risca do começo ao fim as reuniões diárias. Sei que quando as coisas não vão muito bem e apertam-se os prazos a primeira coisa que é cortada, e na minha opnião erroneamente são as reuniões, passando de diárias para esporadicamente 3 ou 2 vezes por semana e assim vai…
E pra finalizar, só pra n perder o costume vlw pelo link da palestra no post Thilafa(Arthemis). Promete e não cumpre…. vacilando como sempre… ai toma uns FB e cai no chão né vaca véia!
Segue o link que ele prometeu da blizzcon dos Geeks!!
http://www.youtube.com/watch?v=Z_uAbmka5Ko
De qq forma vlw a indicação.
Paulo Renan
December 20, 2010 at 19:23
Uma dúvida simples: Qual a(s) maior(es) dificuldade(s) que vocês sentiram/enfrentaram para implementar a metodologia?
PS.: Ótimo Podcast. Consegui entender muito melhor com um exemplo as vantagens da metodologia.
Pingback: DoubleJump