Melhorando os processos nas lojas One-Man GameDev

Como programador de hobby, como posso incorporar um processo de melhoria contínua, como as retrospectivas do Agile em meus processos?

Eu tentei itens de três coisas boas / ruins no final de cada projeto, mas acho que não é suficiente. E sinto que uma retrospectiva do sprint é um exagero. Onde está o equilíbrio? Como posso e devo abrir a porta para a melhoria contínua do processo?

Ou talvez essa pergunta deva estar no site beta do Project Management Stack Exchange ?

Como este é um projeto pessoal, você deve ter muito cuidado para não se atolar no processo. Embora a melhoria contínua seja muito desejável, considere a escolha de elementos do Lean e do Agile que estejam filosoficamente alinhados com a simplicidade de um show individual.

No Scrum e em muitos outros sistemas, as retrospectivas do sprint são benéficas, pois fornecem tempo para uma equipe identificar melhorias. No Lean, muitas vezes há um foco na solução de um problema à medida que ele surge, e acho que é aqui que você pode se beneficiar bastante.

Ao identificar um código ou um problema desagradável, sinalize-o e reserve um momento para fazer o seguinte:

1. Veja onde reside o problema
2. Observe os elementos e sistemas em interação
3. Encontre uma solução rápida (algo que funcione, o que normalmente fazemos e paramos)
4. Identifique a causa raiz (pergunte aos 5 por que )
5. Gere uma solução ou um plano mais satisfatório (possivelmente até padronizado) para uma solução (possivelmente algo a ser implementado após este projeto ou sprint)

Portanto, isso é retirado das cinco regras de ouro do gerenciamento de Gemba e utilizado para combinar com o seu cenário. Até certo ponto, ainda não é super aplicável. Sua milhagem variará e você terá que se adaptar; mas há boas notícias: tudo isso faz parte do Lean!

Você precisa adaptar quaisquer processos que considere "adequados". Isso será algo que você terá que melhorar continuamente, por si só.

Espero que faça sentido. Posso fornecer referências e comentários mais específicos, se desejar.

EDIT (em resposta à pergunta nos comentários):

Para começar, sugiro visitar LeanBlog.org . Você pode querer ler este artigo primeiro. É curto e cheio de citações expressivas. A maior parte é sobre cuidados de saúde; mas você verá rapidamente como isso também se aplica aos jogos.

Para não tocar minha buzina, escrevi um artigo sobre o gamasutra sobre trabalho padronizado e ele tem ótimos recursos na seção de comentários e também idéias. Você pode encontrá-lo aqui.

Eu sugiro que você verifique o blog da Menlo Innovation . A maior parte do que eles falam é aplicável a empresas maiores; mas você deve conseguir adaptá-lo.

Eu estaria interessado em descobrir seus resultados depois de alguns meses :)

Espero que esses links ajudem!

Embora no trabalho usemos o JIRA para esse tipo de coisa, adaptei uma versão para o meu próprio uso no gamedev em casa. Pode ou não ser um sistema que funcione para você, mas eu o adicionarei de qualquer maneira:

1. Pegue algumas fichas e um local para mantê-las - algumas pilhas sobre a mesa funcionam muito bem. Marque essas pilhas como "Não iniciado", "Em andamento", "Bloqueado", "Precisa de melhorias" e "Concluído".
2. Se penso em uma tarefa que precisa ser concluída, escrevo-a imediatamente em um cartão de índice e faço uma estimativa de dificuldade / complexidade
3. Se uma tarefa em que estou trabalhando no momento estiver bloqueada, escrevo o motivo pelo qual
4. A menos que a tarefa seja um bloqueador, não faça isso até que você precise (ou até que você esteja sem tarefas desbloqueadas / em andamento)
5. Se todas as suas tarefas estiverem no estágio Precisa melhorar ou Concluir, comece a trabalhar naquelas que precisam melhorar.
6. ????
7. Lucro!